<PaulFertser>
danergo: are you sure SRAM is mapped to 0x20000000 ? And how much SRAM does your chip have?
<danergo>
I'm having TDI on GPIO29 and TDO on GPIO30. Shall I cross those? Ie.: now CC2652's JTAG_TDI is connected to GPIO29, and JTAG_TDO is connected to GPIO30. Are these fine?
<PaulFertser>
danergo: no, JTAG communication is working, so pinout is correct.
<danergo>
ok
<PaulFertser>
danergo: did you have same commands with the same target working before? What could have changed?
<danergo>
regarding SRAM: tbh I don't know, it's a chip from TI: CC2652R
<PaulFertser>
danergo: don't you have its datasheet handy?
<danergo>
regarding what have been changed: this chip worked before, yes. I changed the RPi which controls the JTAG, it was RPi1, and now it's RPi3
<danergo>
"Use vectreset for CC13xx/CC26xx targets.
<danergo>
nSRST and sysreqreset are both broken for these targets. Upon a
<danergo>
hard reset, the target disables the TDO/TDI pins and the
<danergo>
ICEPick router will remove the target's TAP from the scan
<danergo>
chain. The scripts to do these tasks are run, but then
<danergo>
OpenOCD throws the reset again breaking the debug connection.
<danergo>
Until that issue can be resolved, vectreset is the only
<danergo>
reset that works without breaking the debug connection.
<danergo>
Update: original patch didn't have the correct reset command."
<danergo>
interesting: with debug log3, openocd starts without errors to accept telnet commands
<danergo>
However with debug log1:
<danergo>
Error: JTAG scan chain interrogation failed: all zeroes
<danergo>
Error: Check JTAG interface, timings, target power, etc.
<danergo>
Error: Trying to use configured scan chain anyway...
<danergo>
Error: cc26x2.jrc: IR capture error; saw 0x00 not 0x01
<danergo>
Warn : Bypassing JTAG setup events due to errors
<danergo>
I think this RPi3 is too *fast* for OpenOCD
<danergo>
so if I set loglevel to 3, it has to print commands, which relaxes the signal processing, but if I set loglevel1, it doesn't have to print too much and it doesn't get the right signals
<PaulFertser>
With adapter speed you should be able to make it as slow as needed.
<danergo>
what is the slowest which needs to work?
<danergo>
even 1 is OK?
<PaulFertser>
danergo: you can also try libgpiod driver or sysfsgpio driver, it's very slow.
<PaulFertser>
And more consistent on all SBCs
<danergo>
oh! what about "bcm2835gpio_speed_coeffs" ?
<danergo>
it's "146203 36" for RPi2, and "113714 28" for RPi1
<danergo>
and I have RPi3 which is even faster than RPi2 I think
<danergo>
ahh, and peripheral base address is also changed
<PaulFertser>
With an oscilloscope you'd measure and calculate the right coefficients.
<PaulFertser>
But it might be something else completely. Such as ringing due to lack of termination.
<PaulFertser>
No speed changes can help with that.
<danergo>
I remember doing this on RPi1, but adding resistors didn't help
<danergo>
unfortunately I don't have oscilloscope here >*
<danergo>
:(
<danergo>
setting these values (coeffs, and base address) doesn't make any difference
<danergo>
oh yes, it does:
<danergo>
1.) Reset externally
<danergo>
2.) Start openocd
<danergo>
3.) start telnet, and do "reset halt"
<danergo>
Works
<danergo>
However only IF I use loglevel3
<danergo>
with loglevel1, it doesn't
<danergo>
with loglevel3, it works reliably
<danergo>
with speed 800
<danergo>
so leglevel3 && speed800 works.
<danergo>
loglevel1 && speed100 NOT works
<danergo>
> reset halt
<danergo>
cc26x2.jrc: IR capture error; saw 0x00 not 0x01
<danergo>
Bypassing JTAG setup events due to errors
<danergo>
with loglevel1 && speed10 it seems working
<danergo>
I'll try flashing now with speed10
<danergo>
ahh. with speed10, openocd burns 100% of Pi3's CPU
<danergo>
Or is it intended?
<danergo>
even with 20khz, it burns 100%
<danergo>
and I can only exit with kill -9
<danergo>
it seems intended:O "Programming started" :O
<danergo>
do you know any resources on bcm2835gpio_speed_coeffs ? I wish to understand how are those numbers working
<danergo>
speed10 is the way to make it work, it doesn't matter how I try changing those coeff numbers, I can't even reach 25khz
<PaulFertser>
Yes, openocd just does busy-looping to get the right frequency.
<PaulFertser>
Speed coefficients is a way to specify how to calculate a delay after each transition.
<PaulFertser>
These numbers are explained in the config and user manual, it's just a linear mapping.
Bertl_zZ is now known as Bertl
<danergo>
:) Thank you!
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
danergo has quit [Quit: Client closed]
HelloShitty has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
nerozero has quit [Ping timeout: 260 seconds]
Bertl is now known as Bertl_oO
zjason`` has quit [Read error: Connection reset by peer]
zjason`` has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
sbach has quit [Read error: Connection reset by peer]
erhankur has quit [Remote host closed the connection]
sbach has joined #openocd
erhankur has joined #openocd
wingsorc__ has joined #openocd
wingsorc has quit [Ping timeout: 248 seconds]
wingsorc__ has quit [Ping timeout: 240 seconds]
mnadrian has quit [Ping timeout: 276 seconds]
mnadrian has joined #openocd
wingsorc has joined #openocd
erhankur has quit [Remote host closed the connection]
erhankur has joined #openocd
erhankur has quit [Remote host closed the connection]