Hi Andreas,
The main problem with PSoC6 devices is that CPU must be in Running state in
order to perform Flash Write/Erase operations. Normally this is done by
device boot code and is called TEST MODE. This is how it works:
Immediately after reset PSoC6 devices start to execute boot code. Boot code
enables JTAG/SWD pins and starts to poll TST_MODE register for about 1
millisecond. If boot code detects that 31-st bit in TST_MODE register is
set it will enter infinite loop in "safe place" in ROM and thus will be
ready to perform Flash operations. If 31st bit is not set during 1ms time
window boot code will jump to user application. Debug probe has to set this
bit within 1ms time window after reset in order to enter Test Mode. This
procedure is very time-critical, in Cypress debug probes it is implemented
fully in hardware and does not require any communication with host PC.
Third party debuggers can not enter test mode because of USB latency and
other reasons.
Because we can not enter Test Mode, we have to find a safe way to execute
infinite loop in RAM. By saying "safe way" I mean that we have to find a
way to halt the CPU immediately after reset (prior to execution of user
code). And here comes problem #2: PSoC devices do not support Vector Catch.
Also, they do not support other "clean" reset-halt methods such as
connect-under-reset.
"PSoC6 Programming Specification" document describes alternative
acquisition method which can be used with third-party probes:
1) Halt the device
2) Read Vector Table Offset register and calculate location of ARM Vector
Table (vt_addr)
3) Read (vt_addr + 4) location to determine entry point of user application
(app_main)
4) Set HW breakpoint at app_main
5) Issue SW reset by asserting SYSRESETREQ bit, device will execute boot
code and will halt at breakpoint
6) Remove the breakpoint, write infinite loop opcode to RAM, adjust PC, LR
and SP registers.
7) Set THUMB bit in xPSR
8) Start the CPU. Now PSoC is running infinite loop with all peripherials
in disabled/reset state.
I've tested this procedure with OpenOCD and several JLink probes (Ultra+,
Basic, and cheap Chinese fake) and it works flawlessly.
Thank you for your help Andreas.
I will fix minor coding style issues and submit code to gerrit.
Best regards,
Bohdan
2017-09-25 11:19 GMT+03:00 Andreas Fritiofson <[email protected]>
:
> On Fri, Sep 22, 2017 at 12:16 PM, Bohdan Tymkiv <[email protected]>
> wrote:
>
>>
>> This device requires special acquisition procedure prior to any Flash
>> operation. Acquisition procedure involves setting breakpoint at arbitrary
>> Flash address. Breakpoint can be cleared after acquisition procedure has
>> been completed.
>>
>>
> What do you mean by "acquisition procedure"? What's so special about this
> chip that makes it unable to write flash without explicit breakpoint
> setting?
>
> The problem I am facing is that breakpoints-related API provided by
>> OpenOCD is not easily accessible from within Flash driver code.
>> I have to do ugly things like:
>> #include "../../target/breakpoints.h"
>>
>>
> #include <target/breakpoints.h> should work.
>
> I would like to ask if it is acceptable to set breakpoints from Flash
>> driver code?
>> If not, what is the correct way/location to implement this "acquisition"
>> code?
>>
>>
> If the hardware design requires any special procedures, then it should be
> OK. The flash drivers have full access to all target capabilities, i.e. can
> call any function target_*(), nothing special in that even though no
> current flash driver set breakpoints explicitly.
>
> Procedures like requiring special JTAG scans etc in order to write flash,
> or requiring other calls outside the target layer, well, then it starts to
> get ugly. But if its really needed then there's not much to do if you want
> to support the chip.
>
> /Andreas
>
------------------------------------------------------------------------------
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
