cancel
Showing results for 
Search instead for 
Did you mean: 

GPIO register values not in the documented reset state during debugging

edware
Associate III
Posted on May 14, 2008 at 18:23

GPIO register values not in the documented reset state during debugging

6 REPLIES 6
edware
Associate III
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 ]

16-32micros
Associate III
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

edware
Associate III
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!

niksa
Associate II
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

jgoril
Associate II
Posted on May 17, 2011 at 12:21

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

jj
Associate II
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???