2008-05-14 09:23 AM
GPIO register values not in the documented reset state during debugging
2011-05-17 03:21 AM
I have written a small program (below) to demonstrate a GPIO register not resetting to the expected value when running with Jlink / IAR EWARM.
Does anyone know if there's any way to change the behaviour of the Jlink device to ensure all registers are at their documented reset states after a reset (while debugging)? Or maybe it's my setup...Can anyone else see this issue? (I'm using IAR Kickstart 4.42A with Jlink Version 6) Cheers #define GPIOA_CRL (*((volatile unsigned int *)0x40010800)) /******************************************************************************* * Main program - Showing a GPIOA register not being reset correctly * Dev tools used: * - IAR Embedded Workbench (Kickstart Version 4.42A) * - Jlink debugger Version6 * ST Documentation shows GPIOx_CRL should be 0x44444444 out of reset * Program below shows the GPIOA_CRL is never set to expected value during * debugging *******************************************************************************/ int main(void) { if (GPIOA_CRL == 0x44444444) // This is the (expected) reset value { // STM32 register was reset properly - now change it GPIOA_CRL = 0x88888888; // Set GPIOA to Input with Pullup/down } else // Register not reset correctly { // STM32 register NOT reset correctly! // Change the register to GPIOA_CRL = 0x44444444; // Setup for floating Inputs } while(1); }[ This message was edited by: edware on 14-01-2008 06:15 ]2011-05-17 03:21 AM
Dear edware,
looking at the Reference manual RM0008 Section 5.1.1 , you can see that portA is multiplexed by JTAG pins and at reset some pins of PortA are configured with pull-up and pull-down to enable JTAG and so enabling any tool connection ( IAR, Keil, Raisonnance, Hitex, etc...). Hope this is more clear now :) , Cheers, STOne-322011-05-17 03:21 AM
Thanks for the response STOne-32,
I don't believe the issue is related to the Jtag remapping, as it occurs with most of the STM32 registers...Perhaps I have been unclear in my posting.. I'll try to describe the issue in another way: For example: -Application sets Port B5 to push pull output mode, with a logical 1 output -Using a scope I can see the output goes high (OK) -Reset the system using the IDE reset button (not the nRST pin), no change on PB5! -Exit debug mode, no change on PB5! (still a high output) -Re-enter debug mode, run to main, no change on PB5! (still a high output) -Exit debug mode, no change on PB5! (still a high output) -Press the reset button on eval board (nRST), PB5 goes high impedance (pulldown resistor causes output to fall to 0) I have tried changing the link between TRST (pin 3 of the JTAG connector) and the NRST pin on the micro (pin 7 of the STM32F103RBT6) without success. Q1/ Should the TRST output be asserted when the IDE reset button is asserted? (as I don't see this) Q2/ Are you able to explain this behaviour? Cheers!2011-05-17 03:21 AM
I am using GPIO ports PA13, PA14 and PA15. PA13 and PA14 are connected to LEDs, and after remapping JTAG pins, the LEDs are working fine.
However, I have observed the strange behavior with PA15. After reset, I remap JTAG pins using the following command; GPIO_PinRemapConfig(GPIO_Remap_SWJ_Disable, ENABLE); After that, I set PA15 to high, and it is set to high. Then, I put the processor in Wait-for-interrupt state. PA13 and PA14 continue to be set, but PA15 goes to High-Z state. Can anyone confirm this behavior with PA15 going to HighZ when Wait-for-interrupt state is entered? Is there a way to solve this? Is this just another STM32 undocumented ''feature'' we have to find out? Best regards, Niksa2011-05-17 03:21 AM
May be, your IDE doesn't use NRST pin to reset the device. When connected using JTAG, it is possible to invoke the core reset using DP CTRL/STAT register. You can find more details in ARM Debug Interface v5 Architecture Specification (ARM IHI 0031A) available from ARM (chapter 6. Debug Port Registers). I'm not sure whether this signal invokes only core reset or it resets also peripheral registers. Seems not...
2011-05-17 03:21 AM
edware-
We built/sold/shipped our 1st run STM32 hw - waiting for our new boards or I'd duplicate your set-up and report. However I believe that IAR KS 5.11 ''fixes'' several similar issues. Will run ''real'' test & report back when our boards arrive. niksa- feel you pain. As PA15 is also JTDI wonder if this pin is reverting to input - and not hi-Z? I must confess - using STM32 and other ARMs - we have been afraid to ''divert'' these pins from their JTAG function. (if ANY pins are to behave ''strangely'' - these (Jtag shared) are the most likely!) Lastly - you tie PA13 & PA14 to leds - any chance your PA15 connection is the culprit???