From: Patrick S. <pat...@ne...> - 2014-08-27 17:18:26
|
Hi, I'm trying to get openocd working with a freescale KL26, but it seems to have problems when I try to flash using GDB, the erase command fails after a couple of blocks. The debug log is here: http://pastebin.com/tQYFcHEc Any ideas? I'm using the following commands: interface ftdi ftdi_device_desc "Neul SWD" ftdi_vid_pid 0x5555 0x5556 ftdi_layout_init 0x0038 0x05fb ftdi_layout_signal SWD_EN -data 0 transport select swd set CHIPNAME MKL26Z256VMP4 set _CHIPNAME $CHIPNAME set _ENDIAN little set _WORKAREASIZE 0x1000 set _CPUTAPID 0x0bc11477 swd newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME cortex_m -endian $_ENDIAN -chain-position $_CHIPNAME.cpu $_TARGETNAME configure -event examine-end { kinetis mdm check_security } $_TARGETNAME configure -event gdb-attach { echo "Halting target" halt } $_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0 set _FLASHNAME $_CHIPNAME.flash flash bank $_FLASHNAME kinetis 0x00000000 0x40000 0 4 $_TARGETNAME adapter_khz 1000 cortex_m reset_config sysresetreq gdb_memory_map enable gdb_flash_program enable Possibly related to this, I'm using an FTDI chip directly as the SWD interface. I don't have one of the jtag to swd adapters with buffers on, so I made this (http://openocd.zylin.com/#/c/2274/) modification in order to disable the output during input. Given that it gets quite far and seems to be able to communicate, I'm hoping that that isn't the problem. Best regards, Patrick Stewart | Systems Engineer Phone: +44 1223 755409 | Mobile: +44 7765 690873 | Email: pat...@ne...<mailto:pat...@ne...> Neul Ltd | www.neul.com<http://www.neul.com/> The Internet of Everything |
From: Paul F. <fer...@gm...> - 2014-08-28 10:58:38
|
Hi, On Wed, Aug 27, 2014 at 05:18:15PM +0000, Patrick Stewart wrote: > I'm trying to get openocd working with a freescale KL26, but it seems to have > problems when I try to flash using GDB, the erase command fails after a couple > of blocks. The debug log is here: [1]http://pastebin.com/tQYFcHEc Any ideas? How do you recover from this state? Does power-cycling help? Have you tried connecting reset line and using "reset_config srst_only"? Also, you might want to try configuring gdb-flash-erase-start event to an empty string (so it doesn't reset the target on every erase region) and issue "mon reset init" manually once before "load". I do not really understand what's wrong with the procedure but it looks like resetting the target without the hardware reset line just after the first sector is erased confuses the target. > gdb_memory_map enable > > gdb_flash_program enable These two are defaults, no need to mention them. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Patrick S. <pat...@ne...> - 2014-08-28 16:07:08
|
After this has happened the chip flash becomes protected, and get stuck in a fast reset loop that prevents openocd from talking to it. I've been using a j-link debugger (not with openocd) to get it out of that state. I've been trying it with lots of minor variations in settings, and it actually worked once and I got a fully working debug session. However it wouldn't work again with the same settings, so I think there might be some kind of race/timing issue. Best regards, Patrick -----Original Message----- From: Paul Fertser [mailto:fer...@gm...] Sent: 28 August 2014 11:58 To: Patrick Stewart Cc: ope...@li... Subject: Re: [OpenOCD-user] KL26 flash erase Hi, On Wed, Aug 27, 2014 at 05:18:15PM +0000, Patrick Stewart wrote: > I'm trying to get openocd working with a freescale KL26, but it seems > to have problems when I try to flash using GDB, the erase command > fails after a couple of blocks. The debug log is here: [1]http://pastebin.com/tQYFcHEc Any ideas? How do you recover from this state? Does power-cycling help? Have you tried connecting reset line and using "reset_config srst_only"? Also, you might want to try configuring gdb-flash-erase-start event to an empty string (so it doesn't reset the target on every erase region) and issue "mon reset init" manually once before "load". I do not really understand what's wrong with the procedure but it looks like resetting the target without the hardware reset line just after the first sector is erased confuses the target. > gdb_memory_map enable > > gdb_flash_program enable These two are defaults, no need to mention them. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Paul F. <fer...@gm...> - 2014-08-28 16:10:40
|
Hi, Please avoid top-posting. On Thu, Aug 28, 2014 at 04:06:39PM +0000, Patrick Stewart wrote: > After this has happened the chip flash becomes protected, and get > stuck in a fast reset loop that prevents openocd from talking to > it. Hm, with KL25 mdm command to unlock a protected part works 100% reliably, I know this firsthand. It would be rather cool to get it working for the other kinetis parts as well. > I've been using a j-link debugger (not with openocd) to get it > out of that state. I've been trying it with lots of minor variations > in settings, and it actually worked once and I got a fully working > debug session. However it wouldn't work again with the same > settings, so I think there might be some kind of race/timing issue. So what about my suggestion to nullify the default gdb-flash-erase-start event? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |
From: Patrick S. <pat...@ne...> - 2014-11-06 12:23:12
|
> Hi, > > Please avoid top-posting. > > On Thu, Aug 28, 2014 at 04:06:39PM +0000, Patrick Stewart wrote: > > After this has happened the chip flash becomes protected, and get > > stuck in a fast reset loop that prevents openocd from talking to it. > > Hm, with KL25 mdm command to unlock a protected part works 100% > reliably, I know this firsthand. It would be rather cool to get it working for the > other kinetis parts as well. > > > I've been using a j-link debugger (not with openocd) to get it out of > > that state. I've been trying it with lots of minor variations in > > settings, and it actually worked once and I got a fully working debug > > session. However it wouldn't work again with the same settings, so I > > think there might be some kind of race/timing issue. > > So what about my suggestion to nullify the default gdb-flash-erase-start > event? > > -- > Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! > mailto:fer...@gm... I got this working in the end with your suggestion to override gdb-flash-erase-start, and fixed the mass_erase by adding in a 'reset halt' which prevents the watchdog reset loop. ApoIogies for not replying earlier, and thanks for your help. For anyone who's having similar problems, here's my configs: kinetis-unsecure.cfg: interface ftdi ftdi_device_desc "SWD SPI Debug Interface" ftdi_vid_pid 0x0403 0x7988 ftdi_channel 1 ftdi_layout_init 0x0000 0x000b ftdi_layout_signal nSRST -data 0x0010 -oe 0x0010 ftdi_layout_signal SWD_EN -data 0 ftdi_layout_signal SWDIO_OE -data 0 transport select swd set CHIPNAME MKL26Z256VMP4 set _CHIPNAME $CHIPNAME set _ENDIAN little set _WORKAREASIZE 0x1000 set _CPUTAPID 0x0bc11477 swd newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME cortex_m -endian $_ENDIAN -chain-position $_CHIPNAME.cpu $_TARGETNAME configure -event examine-end { kinetis mdm mass_erase } $_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0 set _FLASHNAME $_CHIPNAME.flash flash bank $_FLASHNAME kinetis 0x00000000 0x40000 0 4 $_TARGETNAME adapter_khz 1000 reset_config srst_only srst_open_drain srst_nogate connect_assert_srst cortex_m reset_config sysresetreq init reset halt shutdown devboard.cfg: interface ftdi ftdi_device_desc "SWD SPI Debug Interface" ftdi_vid_pid 0x0403 0x7988 ftdi_channel 1 ftdi_layout_init 0x0000 0x000b ftdi_layout_signal nSRST -data 0x0010 -oe 0x0010 ftdi_layout_signal SWD_EN -data 0 ftdi_layout_signal SWDIO_OE -data 0 transport select swd set CHIPNAME MKL26Z256VMP4 set _CHIPNAME $CHIPNAME set _ENDIAN little set _WORKAREASIZE 0x1000 set _CPUTAPID 0x0bc11477 swd newdap $_CHIPNAME cpu -irlen 4 -expected-id $_CPUTAPID set _TARGETNAME $_CHIPNAME.cpu target create $_TARGETNAME cortex_m -endian $_ENDIAN -chain-position $_CHIPNAME.cpu $_TARGETNAME configure -event examine-end { kinetis mdm check_security } $_TARGETNAME configure -event gdb-attach { echo "Halting target" reset halt } $_TARGETNAME configure -event gdb-flash-erase-start { halt } $_TARGETNAME configure -work-area-phys 0x20000000 -work-area-size $_WORKAREASIZE -work-area-backup 0 set _FLASHNAME $_CHIPNAME.flash flash bank $_FLASHNAME kinetis 0x00000000 0x40000 0 4 $_TARGETNAME adapter_khz 1000 reset_config srst_only srst_open_drain srst_nogate connect_assert_srst cortex_m reset_config sysresetreq init reset halt |
From: David B. <da...@we...> - 2014-08-29 07:33:18
|
On 28/08/14 18:10, Paul Fertser wrote: > Hi, > > Please avoid top-posting. > > On Thu, Aug 28, 2014 at 04:06:39PM +0000, Patrick Stewart wrote: >> After this has happened the chip flash becomes protected, and get >> stuck in a fast reset loop that prevents openocd from talking to >> it. > > Hm, with KL25 mdm command to unlock a protected part works 100% > reliably, I know this firsthand. It would be rather cool to get it > working for the other kinetis parts as well. > It's been a while since I tried this - I've been busy with other projects. But I never managed to get a K10 unlocked using OpenOCD. I studied the OpenOCD code, and the application notes from Freescale, and could not see any errors - if the chip works as the application notes describe, unlocking should work. I could usually unlock the K10 using a P&E Micro USB debugger and CodeWarror, but sometimes it failed - and a colleague here regularly fails to unlock K10 with the P&E debugger. So while I haven't had the chance to study the issue as much as I want, my gut feeling is that there is some subtle timing issue that is causing trouble. My biggest suspect is the watchdog on the chip - this is enabled out of reset (the Freescale engineer who thought it was a good idea to enable a watchdog from reset should be made to stand in the corner with a dunce hat, along with the one who made the lock bit active when erased). >> I've been using a j-link debugger (not with openocd) to get it >> out of that state. I've been trying it with lots of minor variations >> in settings, and it actually worked once and I got a fully working >> debug session. However it wouldn't work again with the same >> settings, so I think there might be some kind of race/timing issue. > > So what about my suggestion to nullify the default > gdb-flash-erase-start event? > |
From: Paul F. <fer...@gm...> - 2014-08-29 15:12:00
|
On Fri, Aug 29, 2014 at 09:13:52AM +0200, David Brown wrote: > On 28/08/14 18:10, Paul Fertser wrote: > > Hm, with KL25 mdm command to unlock a protected part works 100% > > reliably, I know this firsthand. It would be rather cool to get it > > working for the other kinetis parts as well. > > > > It's been a while since I tried this - I've been busy with other > projects. But I never managed to get a K10 unlocked using OpenOCD. I > studied the OpenOCD code, and the application notes from Freescale, and > could not see any errors - if the chip works as the application notes > describe, unlocking should work. I could usually unlock the K10 using a > P&E Micro USB debugger and CodeWarror, but sometimes it failed - and a > colleague here regularly fails to unlock K10 with the P&E debugger. I think a little trial-and-error will help here. E.g. try to not waiting for Flash Ready bit. Or write to the Mass Erase bit several times in a row. Or assert SRST externally manually etc. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fer...@gm... |