<danergo>
one little thing in texi: "for performance reasons" might be misleading for some future devs at first sight
<danergo>
because it's actually not performance reason, just register limitation, so it's more a software-architecture limitation, hm?
<PaulFertser>
danergo: no, I meant it. If I implement setting GPIOs in different registers it would be more operations and so the tight bitbanging loop will get longer.
<danergo>
ah okay, yes, true
<danergo>
:)
<danergo>
PaulFertser: it's much better now
<danergo>
I changed the 32 gpio to some lower (14), and it started working with some minor issues, like:
<danergo>
occasinally "Error: Invalid ACK (0) in DAP response"
<danergo>
I can live with that
<danergo>
it might depend on the series resistor
<danergo>
and interestingly, in verification phase: this error comes:
<danergo>
this might be needed in between program and verify, but now if I define the srst, a lot of errors appeared
<danergo>
but we might be able to fix the SRST, and then this verification issue might be solved also
Hawk777 has quit [Quit: Leaving.]
<PaulFertser>
danergo: I'd compare the log without SRST and with.
<danergo>
yes, sure. right now I'm using "program xy.bin verify exit". could you please recommend another command if there is a better one for flashing and verification ?
<PaulFertser>
Hm, it looks as if cortex-m always tries to use the CRC algorithm. But then I can't see how it can fail with that message if memory isn't available.
<danergo>
aham. I removed that workarea disabler for now
<danergo>
to have a better view
<PaulFertser>
danergo: program is the tool of choice for fully targets but yours is a bit odd so probably worth trying some different combinations. What it does essentially is "reset init", then "flash write_image erase ..." , then "verify_image" and then optional "reset"
<danergo>
my question is about the last line: "No flashing"
<danergo>
can I trust in this verification in spite of the errors reported during this phase?
<PaulFertser>
Looks like an error in the script. It's supposed to do verification and if it fails then flash. But in your case verification doesn't happen and it should be ignored by it's treated as verification ok for whatever reason.
<danergo>
ok, so I must retry in this case
<PaulFertser>
danergo: probably you should try to use WORKAREASIZE of reasonable size but your memory pointer is wrong?
<PaulFertser>
danergo: in target/cc2538.cfg I do not see working memory specification, have you tried adding it?
<danergo>
no I haven't
<danergo>
I have just added workareasize 0
<danergo>
it was either 0 or either missing
<PaulFertser>
I suggest the opposite, try adding proper workarea specification.
<danergo>
for watchdog I don't know if the firmware has it, but I'd bet for no
<PaulFertser>
Probably the target goes into some sleep mode for a bit, probably there's signal integrity issue (do you have resistors atm?).
<danergo>
100R only on TCK
<PaulFertser>
To make sure it's not a sleep mode I'd monitor it after halt.
<danergo>
aha, so simply add -c "reset halt"?
<PaulFertser>
I'd run telnet and interactively try different things.
<danergo>
aha, reset halt in telnet
<danergo>
okay
<PaulFertser>
-c "reset halt" should work if you do it after "init" (to switch from configuration to run stage).
<PaulFertser>
I'd also try to see how it depends on different adapter speed values.
<danergo>
now, without terminal I ran this: openocd -c "debug_level 2" -f interface/rpi-native.cfg -c "transport select jtag" -f target/ti_cc26x2.cfg -c "adapter speed 900" -c "init; reset halt"
<PaulFertser>
That should provide more data, yes.
<danergo>
but it's already arrived the first Error about invalid ACK
<PaulFertser>
So try the same with different adapter speed.
dreamcat4 has quit [Ping timeout: 245 seconds]
<PaulFertser>
To see how it depends (if it does) on it.
<danergo>
again
<danergo>
(just wrote to have some idea of frequency)
<PaulFertser>
I'd also do another series of experiments with/without series resistors.
<danergo>
yes, now I have a lot of trials to do :)
<danergo>
first thing to make this connection rock-solid by preventing those ACK errors
<danergo>
with either resistors or speed changes
<danergo>
because these are affecting the flashing process as well
<danergo>
but it's strange, as in last 5mins no invalid ACK arrived until now
<danergo>
can I somehow ask openocd to print date tag in front of each logline?
key2 has quit [Read error: Connection reset by peer]
nohit has quit [Read error: Connection reset by peer]
key2 has joined #openocd
nohit has joined #openocd
dreamcat4 has joined #openocd
<danergo>
ts manages that in case others need
<danergo>
obviously after redirecting 2>&1
dreamcat4 has quit [Ping timeout: 252 seconds]
nohit has quit [Ping timeout: 252 seconds]
key2 has quit [Ping timeout: 260 seconds]
nohit has joined #openocd
dreamcat4 has joined #openocd
key2 has joined #openocd
danergo has quit [Quit: Client closed]
godSend23 has joined #openocd
godSend23 has quit [Client Quit]
danergo has joined #openocd
<danergo>
@800kHz with 100R in TCK 2hours passed without any invalid ACK(0) error messages
<danergo>
I think now this is OK :)
<PaulFertser>
danergo: hm, so was it just 900 vs 800 difference?
<danergo>
@800kHz, and from telnet, both flash_write, both verify_image runs successfully
<danergo>
without any single errors
<danergo>
and I don't even have to reset between flash write_image and verify_image
<danergo>
it works safe even with the easy "program" command
<PaulFertser>
danergo: good news!
<danergo>
this is the magic: "init; reset halt; sleep 1000; program .... exit"
<danergo>
this way no telnet is needed
<PaulFertser>
danergo: you take into account "program" does "reset halt" too? I wonder how it can make a difference.
<PaulFertser>
But if it does, well, great you found it.
<danergo>
oh, and adapter speed of 800kHz seems also very important
<PaulFertser>
Probably that's all the trick and you do not need that extra reset halt?
<danergo>
at 1000kHz, Error: error executing cortex_m crc algorithm
<danergo>
reappears
<danergo>
yes, it seems extra reset halt and sleep is not needed
<PaulFertser>
danergo: does that 100R change the result when you use 800 kHz?
<danergo>
I haven't yet tried that out
<danergo>
now 100R is in
<danergo>
I'll try to remove that
<danergo>
but sooner or later I'll get back to the start point :D
<PaulFertser>
danergo: aren't you convinced enough by now that this can be reliable enough for your new PCB project?
<danergo>
maybe the CPU has been "settled" and now it works great
<PaulFertser>
:D
<danergo>
yes, I don't have doubts now, thank you so much! :)
<danergo>
do I need init in this: "init; program .... " ?
<PaulFertser>
danergo: I'm glad I could help, and sorry about that bug. Not that I could predict it back then I guess.
<PaulFertser>
danergo: no, program has implicit init.
<PaulFertser>
Back in 2012 :)
<danergo>
wow. yes time flies :)
<danergo>
oh, i gotta go
<danergo>
thx again!
<PaulFertser>
Good luck, see you
akaWolf has quit [Ping timeout: 260 seconds]
[itchyjunk] has joined #openocd
danergo has quit [Quit: Client closed]
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #openocd
akaWolf has joined #openocd
zjason has quit [Remote host closed the connection]
zjason has joined #openocd
danergo has joined #openocd
<danergo>
PaulFertser: it works as intended without the 100R (based on my experience, it works more solid without that
<danergo>
there were only two bad decision: GPIO selection, and speed
<danergo>
earlier 900kHz worked (kinda), I wrote a script which tries 10 times
<danergo>
but now, different physical env, different wires around (although the module has the very same wires as before): these require lower speed, 800 seems rock-solid
<danergo>
this also solves the SRST problem which we can't solve earlier with 900kHz
<danergo>
thank you so much for your precious time and help!
<danergo>
ah, I was wrong, reset is still not working. (wires were detached :D)
<danergo>
I have to disable reset handling, otherwise I got a lot of
<danergo>
Error: Invalid ACK (0) in DAP response
<danergo>
then one
<danergo>
Error: Could not find MEM-AP to control the core
<danergo>
then
<danergo>
** Unable to reset target **
<danergo>
I'll play with this a little more
<danergo>
and let u know my results
<danergo>
so, here is my observation:
<danergo>
in any case, if I run openocd with only interface and target definition (no init, or reset commands are added):
<danergo>
if I attach telnet to it and run a reset, it will bomb me with invalid ack(0)s
<danergo>
even, if I don't run a reset command, just assert and deassert srst via telnet, same invalid ack(0)s
<bencoh>
do you still "reset halt" though?
<bencoh>
or did you switch to "reset; halt" ?
<danergo>
and if I don't run anything in telnet
<danergo>
but I assert and deassert the target with "gpio write"
<danergo>
same invalid ack(0)s are coming
<danergo>
so it seems, if the target is reset while openocd is attached to it, openocd can't survive and has to be manually killed
<danergo>
bencoh: I tried with "reset run", "reset halt", and also "reset"
<bencoh>
I'm quite certain it doesn't bother openocd that much here, but I might be wrong
<bencoh>
(ie openocd eventually retries and gets a proper answer)
<danergo>
but as it doesn't work even if I do a reset outside of oocd, I guess it's some kind of a driver problem
<bencoh>
could be actually
<bencoh>
if your jtag driver was poorly designed, it might be retrying in a loop
<bencoh>
forever
<danergo>
yes, now I'm 100% sure
<danergo>
invalid ack(0)s are also coming if I reset the target with wires physically
<danergo>
without typing any button on the keyboard
<bencoh>
do you see higher-level messages from openocd between the io-level ack errors?
<danergo>
will level3 be enough?
<danergo>
on level3 no, not really, very rarely one line is between them:
<danergo>
arm_adi_v5.c:900 dap_find_ap(): No AHB3-AP found
<danergo>
anyway, it's full of
<danergo>
adi_v5_jtag.c:425 jtagdp_overrun_check(): Invalid ACK (0) in DAP response
<danergo>
I would need to somehow detach the TAP, and completely reinit the whole statemachine to such state as if oocd just have been started from scratch
<danergo>
I have 0.10 version, what is the fastest way to upgrade to 0.11? possible without compiling, as bcm2835 is not that great on that :D
<danergo>
maybe 0.11 has some upgrades for cc26x2 targets..
<PaulFertser>
danergo: it might be that your target is incompatible with "reset halt" when hardware SRST is used. I would try to use larger (like few seconds) srst delay first to see if reset halt with srst is possible. But even if with big delay it is not, I'd consider it just broken target and you could use "reset; halt" as a workaround instead.
<danergo>
even with as large delay as 5 seconds, it is still invalid acks
<danergo>
reset; halt:
<danergo>
same
<danergo>
I'm going to migrate to bullseye, and retry with 0.11
emeb has joined #openocd
<PaulFertser>
danergo: how do you change delay btw?
<danergo>
with adapter srst delay 5000
<danergo>
can you check my earlier diff on TI's website, if that's still valid?
<danergo>
it talks about "fixing" the reset issue on TI's chips cc13x2 and cc26x2
<PaulFertser>
danergo: probably reset handling in 0.11.0 changed enough. But building OpenOCD on raspberrypi isn't that long, probably 30 minutes, so I'd also try current master.
<danergo>
it's now upgrading to bullseye
<danergo>
we'll see
akaWolf has quit [Ping timeout: 265 seconds]
akaWolf has joined #openocd
nerozero has quit [Ping timeout: 252 seconds]
Hawk777 has joined #openocd
<borneoa_>
danergo: that commit in TI git is also in openocd gerrit. If I remember correctly it breaks on other devices, so was not merged. TI device has some issue with the incorrect double reset sent by openocd. The fix would be more deep in openocd code then TI patch does.
<danergo>
ahha, and that fix is already in 0.11 or not?