This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

OpenOCD 0.8.0 & Custom ARM-Cortex-M3 & STICKY ERROR dumping the on-chip flash

Other Parts Discussed in Thread: SEGGER

OpenOCD 0.8.0 & Custom ARM-Cortex-M3 & STICKY ERROR dumping the on-chip flash
===============================================================================
I have a custom armCortex-M3 based board which I want to read the flash out. I am using OpenOCD 0.8.0 & GDB 7.7 with the Segger J-Link USB JTAG.
$ gdb --version
GNU gdb (Ubuntu 7.7-0ubuntu3.1) 7.7
$ openocd -v
Open On-Chip Debugger 0.8.0 (2014-10-13-10:50)



The config file for the interface J-Link is working properly. As far as I know, some ARMs like lpc17xx from NXP are using the same SoC ARM cortex-M3.
http://www.nxp.com/documents/leaflet/75016846.pdf
What I did is, tweak a bit the config in order to have the right values of my device. These are my changes:
# ARM-Cortex-M3 32 bits with 512kB on-chip Flash and 72kB Local On-Chip SRAM,
set CHIPNAME   customCortexM3
set CPUTAPID   0x4ba00477
set CPURAMSIZE 0x12000
set CPUROMSIZE 0x80000
set CCLK 4000
source [find target/lpc17xx.cfg];  # NXP ARM-Cortex-M3


Next step it's just running OpenOCD can be observed below. But after loading this config into OpenOCD, I run a "init" and "halt" and "dump_image" commands:
$ openocd -f openocd.cfg
Open On-Chip Debugger 0.8.0 (2014-10-13-10:50)
Licensed under GNU GPL v2
For bug reports, read
    http://openocd.sourceforge.net/doc/doxygen/bugs.html
Info : only one transport option; autoselect 'jtag'
adapter speed: 10 kHz
adapter_nsrst_delay: 200
jtag_ntrst_delay: 200
cortex_m reset_config sysresetreq
Warn : Specify TAP 'customARM.cpu' by name, not number 0
trst_and_srst separate srst_gates_jtag trst_push_pull srst_open_drain connect_deassert_srst
Info : Doing init
Info : J-Link initialization started / target CPU reset initiated
Info : J-Link ARM V8 compiled Nov 25 2013 19:20:08
Info : J-Link caps 0xb9ff7bbf
Info : J-Link hw version 80000
Info : J-Link hw type J-Link
Info : J-Link max mem block 9296
Info : J-Link configuration
Info : USB-Address: 0x0
Info : Kickstart power on JTAG-pin 19: 0xffffffff
Info : Vref = 3.649 TCK = 1 TDI = 0 TDO = 1 TMS = 0 SRST = 0 TRST = 0
Info : J-Link JTAG Interface ready
Info : clock speed 10 kHz
Info : JTAG tap: customARM.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Info : TAP customARM+0.cpu does not have IDCODE
Warn : JTAG tap: customARM+0.cpu       UNEXPECTED: 0x00000000 (mfg: 0x000, part: 0x0000, ver: 0x0)
Error: JTAG tap: customARM+0.cpu  expected 1 of 1: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4)
Error: Trying to use configured scan chain anyway...
Warn : Bypassing JTAG setup events due to errors
Info : customARM.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : newtarget: hardware has 6 breakpoints, 4 watchpoints
Info : Halting the CPU
target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0x81000000 pc: 0x000c9b96 psp: 0x200010c4
Info : Scanning the chain
   TapName             Enabled  IdCode     Expected   IrLen IrCap IrMask
-- ------------------- -------- ---------- ---------- ----- ----- ------
 0 customARM.cpu          Y     0x4ba00477 0x4ba00477     4 0x01  0x03
 1 customARM+0.cpu        Y     0x00000000 0x4ba00477     4 0x01  0x03

echo "Info : Dumping flash memory 512kB (from 0x0 to 0x80000)..."
dump_image flashOK.bin 0x0 0x80000

Error: JTAG-DP STICKY ERROR
Error: MEM_AP_CSW 0x23000062, MEM_AP_TAR 0x1004
Error: Failed to read memory at 0x00001004


At this moment, I decide to look into the flashOK.bin file. Apparently, only 4kB are read. I check out the flash banks and I realise that openOCD tell me that
the flash is protected. I am not sure about that, because I am able to read the first block from 0x0 to 0x1000 (4kb)


> flash info 0
#0 : customARM at 0x00000000, size 0x00080000, buswidth 0, chipwidth 0
    #  0: 0x00000000 (0x1000 4kB) protected
    #  1: 0x00001000 (0x1000 4kB) protected
    #  2: 0x00002000 (0x1000 4kB) protected
    #  3: 0x00003000 (0x1000 4kB) protected
    #  4: 0x00004000 (0x1000 4kB) protected
    #  5: 0x00005000 (0x1000 4kB) protected
    #  6: 0x00006000 (0x1000 4kB) protected
    #  7: 0x00007000 (0x1000 4kB) protected
    #  8: 0x00008000 (0x1000 4kB) protected
    #  9: 0x00009000 (0x1000 4kB) protected
    # 10: 0x0000a000 (0x1000 4kB) protected
    # 11: 0x0000b000 (0x1000 4kB) protected
    # 12: 0x0000c000 (0x1000 4kB) protected
    # 13: 0x0000d000 (0x1000 4kB) protected
    # 14: 0x0000e000 (0x1000 4kB) protected
    # 15: 0x0000f000 (0x1000 4kB) protected
    # 16: 0x00010000 (0x8000 32kB) protected
    # 17: 0x00018000 (0x8000 32kB) protected
    # 18: 0x00020000 (0x8000 32kB) protected
    # 19: 0x00028000 (0x8000 32kB) protected
    # 20: 0x00030000 (0x8000 32kB) protected
    # 21: 0x00038000 (0x8000 32kB) protected
    # 22: 0x00040000 (0x8000 32kB) protected
    # 23: 0x00048000 (0x8000 32kB) protected
    # 24: 0x00050000 (0x8000 32kB) protected
    # 25: 0x00058000 (0x8000 32kB) protected
    # 26: 0x00060000 (0x8000 32kB) protected
    # 27: 0x00068000 (0x8000 32kB) protected
    # 28: 0x00070000 (0x8000 32kB) protected
    # 29: 0x00078000 (0x8000 32kB) protected
customARM flash driver variant: 2, clk: 4000kHz

> flash list
{name customARM base 0 size 524288 bus_width 0 chip_width 0}
> flash protect 0
  flash protect bank_id first_sector [last_sector|'last'] ('on'|'off')
in procedure 'flash'
> flash protect 0 0 1 off
cleared protection for sectors 0 through 1 on flash bank 0


However, I cannot reach memory areas. I read about the STICKY error for a big while. First tips are to use upper and lower clocks speeds. I tried a lot without success.
I decided to activate the debug mode to level3.
Debug: 482 4571 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_echo
Debug: 483 4571 command.c:145 script_debug(): command - echo ocd_echo
User : 485 4631 command.c:763 jim_echo():
Debug: 486 4631 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_echo Info : Dumping flash memory 512kB (from 0x0 to 0x80000)...
Debug: 487 4631 command.c:145 script_debug(): command - echo ocd_echo Info : Dumping flash memory 512kB (from 0x0 to 0x80000)...
User : 489 4691 command.c:763 jim_echo(): Info : Dumping flash memory 512kB (from 0x0 to 0x80000)...
Debug: 490 4691 command.c:145 script_debug(): command - ocd_command ocd_command type ocd_dump_image flashOK.bin 0x0 0x80000
Debug: 491 4691 command.c:145 script_debug(): command - dump_image ocd_dump_image flashOK.bin 0x0 0x80000
Debug: 493 4751 target.c:1916 target_read_buffer(): reading buffer of 4096 byte at 0x00000000
Debug: 494 18844 target.c:1916 target_read_buffer(): reading buffer of 4096 byte at 0x00001000
Debug: 495 32927 adi_v5_jtag.c:271 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT error, 0xf0000021
Debug: 496 32927 adi_v5_jtag.c:291 jtagdp_transaction_endcheck(): MEM-AP Cached values: ap_bank 0x0, ap_csw 0xa2000022, ap_tar 0x1000
Error: 497 32927 adi_v5_jtag.c:298 jtagdp_transaction_endcheck(): JTAG-DP STICKY ERROR
Debug: 498 32949 adi_v5_jtag.c:315 jtagdp_transaction_endcheck(): jtag-dp: CTRL/STAT 0xf0000001
Error: 499 32982 adi_v5_jtag.c:331 jtagdp_transaction_endcheck(): MEM_AP_CSW 0x23000062, MEM_AP_TAR 0x1004
Error: 500 33012 arm_adi_v5.c:512 mem_ap_read(): Failed to read memory at 0x00001004
Debug: 501 33012 command.c:628 run_command(): Command failed with error code -107
User : 502 33012 command.c:666 command_run_line(): Runtime Error: openocd.cfg:67:
in procedure 'script'
at file "embedded:startup.tcl", line 58
in procedure 'dump_image' called at file "openocd.cfg", line 67



After that, I watched why the code was crashing and I deleted the STICKYERR flag in the source code. Obviously, the flash
dumping looked working, but the data was all zeroes.
Info : Dumping flash memory 512kB (from 0x0 to 0x80000)...
dumped 524288 bytes in 1803.287476s (0.284 KiB/s)


I do need to read the on-chip flash of this board. It is my personal challenge. Any feedback is always welcome. Now I am stuck why I am not able to read the whole flash.

Cheers,  
   Edu

  • Hi,

    Please specify exactly the brand of your micro. Even it is Cortex-M3,  each brand has its own technology to build micros, and different hardware implementations; OpenOCD takes these into account and has separate configuration files for the JTAG/SWD interfaces. 

    Without being sure you what is your micro, you cannot apply the first configuration at hand, even for NXP micros.

    Petrei

  • I do need to read the on-chip flash of this board. It is my personal challenge.

    To reverse engineering its firmware ?

    Now I am stuck why I am not able to read the whole flash.

    Probably the developer/vendor of this device took advantage of its capabilities to protect the Flash from readout/debugging, a feature that all Cortex M chips on the market have.

  • Hi Petrei

    I agree. To me it seems to be a non-TI part (logs from openocd with nxp cfg file can be misleading though)

    Regards

    Amit

  • @f.m.

    f. m. said:
    To reverse engineering its firmware ?

    Something like that ;)

    f. m. said:
    Probably the developer/vendor of this device took advantage of its capabilities to protect the Flash from readout/debugging, a feature that all Cortex M chips on the market have.

    Indeed, but how I can be 100% sure of that. I do need an empirical proof. Is there some way to test it? Right?

    @Petrei:   

    Petrei said:
    Please specify exactly the brand of your micro. Even it is Cortex-M3,  each brand has its own technology to build micros, and different hardware implementations; OpenOCD takes these into account and has separate configuration files for the JTAG/SWD interfaces. 


    Unfortunately, I cannot mention the brand. However, I can respond you any detail about it.  I set up the CPU, SRAM, and FLASH. What else do we need to run a basic go?

    Petrei said:
    Without being sure you what is your micro, you cannot apply the first configuration at hand, even for NXP micros.Petrei

    custom  32 bits ARM-Cortex-M3 . What else do you need?

  • Hello edu,

    Since it is a non-TI part on a TI-forum, the advise would be to go to OpenOCD folks...

    Regards

    Amit

  • Hi,

    I agree with Amit. Not further help with this thread from me.

    Petrei