GPIO register values not in the documented reset state during debugging

Posted on May 17, 2011 at 12:21

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 ]

Posted on May 17, 2011 at 12:21

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!

Posted on May 17, 2011 at 12:21

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-32

Posted on May 17, 2011 at 12:21

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,

Niksa

Posted on May 17, 2011 at 12:21

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???