[Openocd-development] Reset halt issues with EK-LM3S9B92
[I accidentally sent this from the wrong email address. I'm resending from the correct (subscribed) address. My apologies if both arrive.] I'm having problems with reset halt and reset init with the EK-LM3S9B92, both with 0.4.0 and the latest git. I'm starting openocd using openocd -f board/ek-lm3s9b9x.cfg A reset halt command gives me the following: reset halt JTAG tap: lm3s9b9x.cpu tap/device found: 0x4ba00477 (mfg: 0x23b, part: 0xba00, ver: 0x4) Halt timed out, wake up GDB. timed out while waiting for target halted TARGET: lm3s9b9x.cpu - Not halted Command handler execution failed in procedure 'reset' called at file command.c, line 650 called at file command.c, line 361 The halt command works fine. It's only reset halt and reset init that fail. The fitted MCU is an LM3S9B92 rev B1 (DID0=0x10040101). I've seen the comments about lm3s in cortex_m3_assert_reset() in src/target/cortex_m3.c, so I tried adding assert_srst = 0; to the Tempest case as well, and this makes reset halt work perfectly. I have no idea if this is because the Tempest is affected by the same issue as the other lm3s MCU:s, or if it's something else. Is it possible to confirm if my fix is correct, or if it just happens to work? /Tobias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Reset halt issues with EK-LM3S9B92
On 04/27/2010 03:38 PM, Øyvind Harboe wrote: Could you attach a patch? Of course, but as I said, I don't know for certain that this is a correct fix or not. I also don't know if it is needed only for certain revisions of the device (= B1). It would be nice if someone with a C1 or C3 rev Tempest could test reset halt. On the other hand, maybe the software reset works just as fine a hardware reset, so it doesn't really matter. The comment says that nRST clears some of the debug state for some LM3S devices. Would it be possible to test for that instead of revision numbers? /Tobias diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c index 7f6cbaf..44bf466 100644 --- a/src/target/cortex_m3.c +++ b/src/target/cortex_m3.c @@ -910,7 +910,7 @@ static int cortex_m3_assert_reset(struct target *target) assert_srst = 0; break; case 4: - /* Tempest should be fine. */ + assert_srst = 0; break; } } ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] [PATCH] STM32 flash erase timeout fix
The current timeout for STM32 flash block erase and flash mass erase is 10 (ms), which is too tight, and fails around 50% of the time for me. The data sheet for STM32F107VC specifies a maximum erase time of 40 ms (for both operations). I'd also consider it a bug that the code does not detect a timeout, but just assumes that the operation has completed. The attached patch does not address this bug. The attached patch increases the timeouts from 10 to 100 ms. Please apply. /Tobias diff --git a/src/flash/nor/stm32x.c b/src/flash/nor/stm32x.c index 818c474..0fdd148 100644 --- a/src/flash/nor/stm32x.c +++ b/src/flash/nor/stm32x.c @@ -331,7 +331,7 @@ static int stm32x_erase(struct flash_bank *bank, int first, int last) target_write_u32(target, STM32_FLASH_AR, bank-base + bank-sectors[i].offset); target_write_u32(target, STM32_FLASH_CR, FLASH_PER | FLASH_STRT); - status = stm32x_wait_status_busy(bank, 10); + status = stm32x_wait_status_busy(bank, 100); if (status FLASH_WRPRTERR) return ERROR_FLASH_OPERATION_FAILED; @@ -1183,7 +1183,7 @@ static int stm32x_mass_erase(struct flash_bank *bank) target_write_u32(target, STM32_FLASH_CR, FLASH_MER); target_write_u32(target, STM32_FLASH_CR, FLASH_MER | FLASH_STRT); - status = stm32x_wait_status_busy(bank, 10); + status = stm32x_wait_status_busy(bank, 100); target_write_u32(target, STM32_FLASH_CR, FLASH_LOCK); ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] STM32 flash erase timeout fix
On 2010-05-02 18:52, Øyvind Harboe wrote: 2010/4/30 Tobias Ringströmtob...@ringis.se: The current timeout for STM32 flash block erase and flash mass erase is 10 (ms), which is too tight, and fails around 50% of the time for me. The data sheet for STM32F107VC specifies a maximum erase time of 40 ms (for both operations). I'd also consider it a bug that the code does not detect a timeout, but just assumes that the operation has completed. The attached patch does not address this bug. The attached patch increases the timeouts from 10 to 100 ms. Please apply. Sounds sensible to me. Any objections to merging? What do you mean? /Tobias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH] STM32 flash erase timeout fix
On 2010-04-30 14:20, freddie_cho...@op.pl wrote: Użytkownik Tobias Ringströmtob...@ringis.se napisał: The current timeout for STM32 flash block erase and flash mass erase is 10 (ms), which is too tight, and fails around 50% of the time for me. The data sheet for STM32F107VC specifies a maximum erase time of 40 ms (for both operations). Never happened for me in a few different designs... The delay value of 10 was just at the edge for me as it failed for about 50% of the blocks. I guess you have a slower JTAG and/or computer. Nevertheless, if the specification says it can take 40 ms, openocd should certain allow for that much time. It's also only a timeout, so increasing it will not have any effect on performance. Also note that erase didn't complain at all. It was flash write_image that complained later on that not all blocks were erased. /Tobias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] Reset halt issues with EK-LM3S9B92
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/11/2010 09:53 PM, Spencer Oliver wrote: On 11/05/2010 18:22, Øyvind Harboe wrote: So should we just apply this patch you think? Possibly limiting the revision to = B1. I don't have access to a later revision chip, and I will most likely never get that since we've decided to switch to the STM32 because of the inferior ethernet peripheral in the LM3S. The STM32 has other shortcomings, of course. Let me know if you want me to provide another patch. Do not have any tempest silicon to test, but it sounds as if they forgot to fix this old bug. Tobias, Can you confirm that the srst pin is actually getting asserted/released? Yes. Verified using oscilloscope. Another test is to hold the reset button down then run openocd, after a couple of seconds release the reset button. I don't understand what I should look for. If I press reset before starting openocd and release it 2 seconds after openocd is started, openocd start up normally. If I release it 3 seconds after starting openocd, I get this: srst_only separate srst_gates_jtag srst_open_drain Info : clock speed 500 kHz Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Error: JTAG scan chain interrogation failed: all ones Error: Check JTAG interface, timings, target power, etc. Command handler execution failed Warn : jtag initialization failed; try 'jtag init' again. /Tobias -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkvqlwAACgkQoVlA9AKQ7+xt6wCfa0w5tjSzhUW1X43TlfaUQaDM xDcAn1k4BPVYp+FnISSaj3TGIAdruYnQ =doNd -END PGP SIGNATURE- ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] [PATCH 3/3] stm32: add stm32 xl family flash support
On 12/23/2010 10:09 AM, Spencer Oliver wrote: I am going to have a change around for the stm32 flash as i am also working on a flash driver for the stm32lx and stm32f2x. An eval board with an stm32f207 just landed on my desk, and I was not aware that it wasn't supported by OpenOCD until a few minutes ago. I was just looking at adding support for it when I saw your post. How far along are you with the stm32f2x support? Is there anything I can do to help? /Tobias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
[Openocd-development] arm-none-eabi-gdb 7.3 error: Remote 'g' packet reply is too long
After updating to GDB 7.3 from 7.2, I can no longer connect to openocd (git version from couple of days ago). The target is a Cortex-M3 STM32F207, and I start openocd using: openocd -f interface/jlink.cfg -f target/stm32f2x.cfg The output from GDB looks like this: arm-none-eabi-gdb -n bootflasher.elf GNU gdb (GDB) 7.3 Copyright (C) 2011 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as --host=x86_64-unknown-linux-gnu --target=arm-none-eabi. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/... Reading symbols from prog.elf...done. (gdb) target remote localhost: Remote debugging using localhost: Remote 'g' packet reply is too long: 0100 /Tobias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
Re: [Openocd-development] arm-none-eabi-gdb 7.3 error: Remote 'g' packet reply is too long
On 08/25/2011 02:17 PM, Øyvind Harboe wrote: On Thu, Aug 25, 2011 at 2:16 PM, j. m. norrisu17...@att.net wrote: Would it make sense for someone to collect a 'wish list' of 'architectures and registers' and then prioritize it? Ultimately we need patches :-) It doesn't matter if we want something but nobody can work on it, but perhaps it could be good as a starting point for a discussion? I thought that with a list, it would hopefully avoid someone working on something and then discovering that no one wanted it. While this situation would generate much appreciated patches, I was hoping to allow for the identification of the most needed amongst the numerous ARM processors / variants. GDB actually has a protocol defined to handle all the variants, so once that feature is implemented, we're done. As I understand it. W.r.t. the gdb register packet that is. I investigated a bit, and openocd needs to provide an XML target description (qXfer:features:read) to GDB that supports it (qSupported:xmlRegisters). It's also possible to provide a target description XML file directly to GDB using the following GDB command: set tdesc filename file name Here's an XML file that can be used to make GDB 7.3 able to talk to openocd and ARM targets (at least EABI ARM): ?xml version=1.0? !DOCTYPE target SYSTEM gdb-target.dtd target feature name=org.gnu.gdb.arm.core reg name=r0 bitsize=32 type=uint32/ reg name=r1 bitsize=32 type=uint32/ reg name=r2 bitsize=32 type=uint32/ reg name=r3 bitsize=32 type=uint32/ reg name=r4 bitsize=32 type=uint32/ reg name=r5 bitsize=32 type=uint32/ reg name=r6 bitsize=32 type=uint32/ reg name=r7 bitsize=32 type=uint32/ reg name=r8 bitsize=32 type=uint32/ reg name=r9 bitsize=32 type=uint32/ reg name=r10 bitsize=32 type=uint32/ reg name=r11 bitsize=32 type=uint32/ reg name=r12 bitsize=32 type=uint32/ reg name=sp bitsize=32 type=data_ptr/ reg name=lr bitsize=32/ reg name=pc bitsize=32 type=code_ptr/ reg name=cpsr bitsize=32 regnum=25/ /feature feature name=org.gnu.gdb.arm.fpa reg name=f0 bitsize=96 type=arm_fpa_ext regnum=16/ reg name=f1 bitsize=96 type=arm_fpa_ext/ reg name=f2 bitsize=96 type=arm_fpa_ext/ reg name=f3 bitsize=96 type=arm_fpa_ext/ reg name=f4 bitsize=96 type=arm_fpa_ext/ reg name=f5 bitsize=96 type=arm_fpa_ext/ reg name=f6 bitsize=96 type=arm_fpa_ext/ reg name=f7 bitsize=96 type=arm_fpa_ext/ reg name=fps bitsize=32/ /feature /target Just save it as target.xml, and add the following line to .gdbinit: set tdesc filename target.xml /Tobias ___ Openocd-development mailing list Openocd-development@lists.berlios.de https://lists.berlios.de/mailman/listinfo/openocd-development
