Hi Bohdan,
On 21.11.2017 14:55, Bohdan Tymkiv wrote:
>> psoc6.cpu.cmX configure -event reset-deassert-post
> PSoC6 clears AP TAR and OpenOCD does not know about it - ROM 0 is
read instead of DHSCR.
> arp_examine should be added to both post-deassert event handlers.
> mww does not work in 'reset_config srst_only'
> Direct write to DCB_DHCSR should be avoided as OpenOCD maintains
internal cache of this register and uses other bits.
I have not found a nice way to forcibly halt the CPUs without writing
to DHCSR.
target->state is set to TARGET_RESET when reset-deassert-post handler
is called, because of this any calls to halt/arp_halt (which ends up
in cortex_m_halt) are basically ignored. The only workaround I've
found is to manually poll target several times (so OpenOCD will detect
that target is actually running) and then call arp_halt.
reset-deassert-post handlers look like this:
psoc6.cpu.cmX arp_examine
psoc6.cpu.cmX arp_poll #state == RESET
psoc6.cpu.cmX arp_poll #state == RUNNING
psoc6.cpu.cmX arp_halt #state == RUNNING so arp_halt works
In the meantime I sent you a proposed reset-deassert-post handler in an
e-mail (not cc-ed to mailing list).
It probably get lost.
I see your solution is very close...
# Utility to make 'reset halt' work as reset;halt on a target
# It does not prevent running code after reset
proc psoc6_deassert_post { target } {
# PSoC6 cleared AP registers including TAR during reset
# Force examine to synchronize OpenOCD target status
$target arp_examine
global RESET_MODE
if { $RESET_MODE ne "run" } {
$target arp_poll
set st [$target curstate]
if { $st eq "reset" } {
# we assume running state follows
# if reset accidentally halts, waiting is useless
catch { $target arp_waitstate running 100 }
set st [$target curstate]
}
if { $st eq "running" } {
echo "$target: Ran after reset and before halt..."
$target arp_halt
}
}
}
${TARGET}.cm0 configure -event reset-deassert-post "psoc6_deassert_post
${TARGET}.cm0"
${TARGET}.cm4 configure -event reset-deassert-post "psoc6_deassert_post
${TARGET}.cm4"
> Flash support: CM4 banks does not work:
>> flash info 6
> Timeout polling IPC Lock Status
This is expected.
Banks 6...11 are assigned to CM4 core, so flash algorithm will run on CM4.
Posted NMI will never be execured by CM0+ because it is halted.
This will also happen if you will try to program flash via CM4 target.
The only possible solution here is to switch to CM0+ AP prior to
calling target_run_algorithm.
Unfortunately, I have no idea how to do this nicely.
I supposed it. It seems me perfectly OK to respect that CM4 core has no
flash programming capability
and therefore refuses programming. Just show a more explaining message than
"Timeout polling IPC Lock Status"
So the only reason for banks 6..11 existence is sending correct memory
map to gdb?
>> cortex_m reset_config sysresetreq
> Is this intentionally for one target only?
> If not, target prefix does not work in second level commands - see #4130
Ideal solution here would be to use SYSRESETREQ for CM0+ and VECTRESET
for CM4.
I was not able to configure reset_config properly up until now.
Today, after long trial and error, it turned out that this requires
special ordering of commands in cfg file.
The following order does not work:
target create ${TARGET}.cm0 ...
target create ${TARGET}.cm4 ...
${TARGET}.cm0 cortex_m reset_config sysresetreq
${TARGET}.cm4 cortex_m reset_config vectreset
But the following works:
target create ${TARGET}.cm0 ...
${TARGET}.cm0 cortex_m reset_config sysresetreq
target create ${TARGET}.cm4 ...
${TARGET}.cm4 cortex_m reset_config vectreset
It seems like reset_config is applied to last defined target, not to
specified ${TARGET}.cmX ( because of #4130 ???)
I will change the ordering in cfg file so correct reset methods will
be used.
Commands on second and higher child level like 'cortex_m reset_config'
simply ignore the target prefix
and incorrectly use current target. You can switch it by 'targets xx'
command.
Don't bother with it, we have to fix the problem...
> OpenOCD debugging is somewhat shaky. Time to time a random error
happens.
Debugging experience highly depends on project you are trying to debug.
Two cores in PSoC6 are not completely independent. For instance, if
CM0+ is reset - it will break debugging session for CM4.
If one core runs through boot code - this will affect state of the
other core, etc.
I am using two very basic projects (LED blinking, gcc/makefile based),
openocd works like a charm during debugging. I don't see any issues at
all.
I will send you sources and configuration files when I'll be back in
the office.
I encountered USB comm message usually once during long flash operation
- programming
or blank check (both cores were actually stopped, so better to say
flashing than debugging).
I'll recheck it on another PC to eliminate problems with USB compatibility.
BTW erase check is hell slow as it runs algorithm for each sector and
PSoC6 flash has a lot of short sectors.
We know how to solve the problem but nobody has time to do it.
Tom
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
OpenOCD-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openocd-devel
