<danergo>
But then I got a lot of ack(0) errors in jtag operation
<danergo>
Maybe i have to play with delays?
<danergo>
Srst is the thing I need, right?
<danergo>
It can do the same as me with setting gpio levels?
<PaulFertser>
danergo: there're two ways to reset a target: hardware reset line and software "sysresetreq" method.
<PaulFertser>
danergo: if you're able to flash then you should be able to reset via software as well. Just do not specify any reset_config at all, and it'll use sysresetreq with modern cortex-m targets.
<PaulFertser>
danergo: alternatively, connect reset line, use reset_config srst_only, and it'll pulse the line when you do "reset" (you can see it in -d3 log, it will for sure)
<danergo>
I didnt specify any reset config, and it warns me that it resets only the cortex-m core.
<PaulFertser>
danergo: you can configure reset pulse width and delay after that, should be all in the user manual.
<PaulFertser>
danergo: so using vectreset? Might be in case "cortex_m sysresetreq" isn't used. Is your target supposed to support that? It should if it's a recent sane target.
<danergo>
And then I cant use the firmware until i manually assert and deassert the nreset
<danergo>
So I need to "simulate" my manual reset operation
<PaulFertser>
danergo: i suggest you try sysresetreq
<danergo>
Yes ,
<danergo>
That works I guess. As it says flashing was okay, verification okay
<danergo>
Command returns with 0 as resultcode
<PaulFertser>
danergo: please reread what I wrote :)
<PaulFertser>
And cross-check with the user manual.
<danergo>
Yes, sorry Im slow (on phone)
<danergo>
So if I dont define any reset config, flashing works, but warns it will only reset the cortexm core. And after this, I am not able to use the device until manually assert deassert of nreset. However if I define resrt config to srstonly, flashing fails with ACK(0) during jtag communications.
<PaulFertser>
danergo: what if you tell openocd to use sysresetreq instead of vectreset?
<danergo>
That one I will have to check later Paul, thx. :)
<PaulFertser>
danergo: if it doesn't help, tune "adapter reset" delay, probably you just need to tell OpenOCD to wait for a little longer after hardware reset.
<danergo>
Ahha
<danergo>
Okay
<danergo>
I just wanted to confirm that srst is the way to go for simulating my manual operation
<danergo>
Thank you!
<PaulFertser>
danergo: :)
<Haohmaru>
whoever suggested i check the samd2x SVD - wowz, how much wrong stuff there
<Haohmaru>
they clearly aren't using those .svd files to generate their headers 101%
tarekb has joined #openocd
tarekb has quit [Read error: Connection reset by peer]
indy has quit [Ping timeout: 245 seconds]
indy has joined #openocd
Fleck has joined #openocd
elpee has quit [Quit: Client closed]
danergo89 has joined #openocd
<danergo89>
\o/
<danergo89>
can anyone confirm that in case of flashing with a rpi, there are no pin restrictions for TMS, TCK, TDI and TDO?
<danergo89>
I mean.. can I use any of the free gpios for any function in [TMS, TCK, TDI, TDO]?
<danergo89>
or the pin has to be, hm, pwm, uart, or whatever?
emeb has joined #openocd
bencoh has joined #openocd
<danergo89>
unfortunately, if I enable srst, it ruins the flashing process entirely
<danergo89>
invalid ACK (0) in DAP response
<danergo89>
this comes a million times
<danergo89>
if I don't enable srst, flashing can be done with some warns:
<danergo89>
Only resetting the Cortex-M core, use a reset-init event handler to reset any peripherals or configure hardware srst support.
<danergo89>
no matter how high timings I set, it always fails
<danergo89>
:(
<danergo89>
Error: Debug regions are unpowered, an unexpected reset might have happened
<danergo89>
unexpected? no. openocd asked for reset, how the **ll can it be then unexpected?
<danergo89>
then Error: JTAG-DP STICKY ERROR
<danergo89>
then Error: Could not find MEM-AP to control the core
<danergo89>
and then million times of "Error: Invalid ACK (0) in DAP response"
<bencoh>
I might be wrong, but it sounds like resetting the cpu resets the tap as well - maybe try srst_pulls_trst?
elpee has joined #openocd
<danergo89>
Error: Debug regions are unpowered, an unexpected reset might have happened │
<danergo89>
Error: JTAG-DP STICKY ERROR │
<danergo89>
Error: Could not find MEM-AP to control the core │
<danergo89>
Error: can't request a halt while in reset if nSRST pulls nTRST │
<danergo89>
** Unable to reset target **
<danergo89>
in case srst_pulls_trst
<danergo89>
thanks anyway :)
<danergo89>
the problem is, if I do this manually, ie, by my hand, joining two wires, it behaves normally.
<danergo89>
now I have pulse_width of 1000 and srst delay of 2000
<PaulFertser>
danergo: so have you tried enabling sysresetreq?
<danergo89>
sorry, I've lost our last few msgs. how can I enable it? I tried putting it into my "rpi1.cfg", but it is not working, also tried putting it into "openocd.cfg", but also not working there
<danergo89>
it says: invalid command name 'cortex_m'
<PaulFertser>
danergo: you were supposed to find the right command in the user manual, not to copy verbatim my message :)
<PaulFertser>
danergo89: so reset halt doesn't work, but do you really need it?
<danergo89>
actually, I'm trying to make reset working:
<PaulFertser>
danergo89: for reset you need plain "reset" or "reset run" (it's the same command)
<danergo89>
1.) without manually controlling GPIO (let openOCD reset when it needs)
<danergo89>
2.) I want OpenOCD to perform a reset when it's ready, otherwise firmware is not usable
Haohmaru has quit []
<PaulFertser>
danergo89: yes, so why are you trying "reset halt" instead of "reset"?
_franck_0 has joined #openocd
<danergo89>
let me try this out
<danergo89>
I feel so lame.. :D
_franck_ has quit [Ping timeout: 268 seconds]
_franck_0 is now known as _franck_
<danergo89>
no, reset performs the same as "reset halt".
<danergo89>
in both of "sysresetreq" and "srst"
<PaulFertser>
danergo89: but probably it doesn't matter since the target is already flashed?
<danergo89>
(I tried those separately)
<danergo89>
yes, the target is flashed, but I'll have to flash another xy pieces, and I really want to make this work without manual intervention if possible :)
<PaulFertser>
danergo89: yes, so try using sysresetreq and "reset" after your last flashing command.
_franck_5 has joined #openocd
<danergo89>
no, it doesn't go well (same output) :(
<PaulFertser>
danergo89: but same output after flashing?
<PaulFertser>
danergo89: that would mean the target actually resetted I guess
<danergo89>
still no :( I got a lot of "Error: Invalid ACK (0) in DAP response"
<danergo89>
I would think this is a wiring problem, but if we skip the reset, it can actually flash the target
elpee has quit [Quit: Client closed]
zmatt has quit [Ping timeout: 245 seconds]
<PaulFertser>
danergo89: so skip the first reset
<PaulFertser>
danergo89: and see if the firmware starts after flashing that way.
<danergo89>
yes, flashing is done this way, then comes the storm of invalid ACKs
<danergo89>
I guess due to the last "reset" instruction
<danergo89>
I mean the only "reset" instruction
<PaulFertser>
danergo89: but probably the target really resets and so the storm can be ignored?
<danergo89>
let me check
<danergo89>
unfortunately, the storm has to be interrupted by ctrl+c, otherwise i don't have the possiblity to verify if it resets or not
<danergo89>
hm. actually this command doesn't verify the firmware. after the flashing, there comes the storm, and not the verification
<danergo89>
openocd tries to reset I guess after flush write_image
<PaulFertser>
danergo89: ok, then I suggest to connect hardware srst line, specify its GPIO number and instead of reset use "adapter assert srst; adapter deassert srst"
<danergo89>
aham, that sounds indeed a great idea, thank you, will test it right now
<PaulFertser>
But that doesn't solve the verification problem.
<danergo89>
actually, this also doens't work :( as if I define srst, flash image_write will try resetting between write and verify, and then there comes the storm
<danergo89>
so the only thing seems working is to completely disable every reset function, and do some gpio write xy 0; sleep 1; gpio write xy 1;
<danergo89>
but then I got some warnings from openocd that it only resets the cortex-m's core
<danergo89>
this is not blocking or mandatory, but is there any config to hide those reset warnings? as I don't need them, in case of cc2652 reset is not working, no need to warn
<PaulFertser>
danergo89: I suggest to keep reset_config none, do not enable srst.
<PaulFertser>
danergo89: if you're not using any reset commands in openocd then it shouldn't be complaining
<danergo89>
and the command "openocd" returns with 0 as return code
<danergo89>
if there is an error in general, openocd usually returns with 1
<danergo89>
showing there was some trouble during flashing operation
<PaulFertser>
danergo89: hm, probably then it's not successful. To make sure it verifies without running target algorithm you can "set WORKAREASIZE 0" or just change the target config to not specify any working area.
<PaulFertser>
Then it wouldn't be trying to run any target algorithms (on the target cpu) at all.
<PaulFertser>
danergo89: it's interesting that you show that lines, it means "program" works and "program" does "reset halt" as its first step.
<danergo89>
yes, but I don't have any srst
<danergo89>
defined
<danergo89>
and I lowered the debug messages to errors only
<danergo89>
I'm just learning the configs :)
<danergo89>
what does this WORKAREASIZE mean?
<danergo89>
during verification
<PaulFertser>
danergo89: I hoped it's the name of the variable that defines working area size in the target config. But probably your target config isn't using it, you should check.
<danergo89>
it tries to calculate some crc into some memory segments on the target?
<PaulFertser>
danergo89: working area is the target's RAM area where openocd uploads small helper code snippets.
<PaulFertser>
danergo89: it tries to run crc calculation function on the target itself.
<danergo89>
perfect, that info was I interested in :)
<PaulFertser>
Helper functions are used by many flashing drivers too, and that's usually much faster. No idea if your target has that helper code or not.
<danergo89>
aha, actually that error message doesn't come at 100% reproducability
<danergo89>
I just have seen it sometimes
<PaulFertser>
Probably the jtag connection is still not fully reliable?
<PaulFertser>
Have you checked signal integrity?
zmatt has joined #openocd
akaWolf has joined #openocd
danergo89 has quit [Quit: Client closed]
zjason has quit [Read error: Connection reset by peer]
zjason has joined #openocd
sbach has quit [Read error: Connection reset by peer]