Why would the S32 lock up after reading a GPIO PCR?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Why would the S32 lock up after reading a GPIO PCR?

Jump to solution
2,340 Views
gearhead1107
Contributor IV

I'm currently trying to debug the interaction of a boot-loader and firmware load, and having some issues that seem to be GPIO related. In both programs I'm using the NXP drivers for GPIO initialization, and in PINS_Init() there's a line that tries to read the PCR values:

uint32_t regValue = config->base->PCR[config->pinPortIdx];

In assembly, there's a LDR.W instruction which is trying to pull values from the 0x4004D040 address:

ldr.w   r3, [r3, r2, lsl #2] ;Note that R3=0x4004D000 and R2=0x10 here

Immediately after this instruction, the processor hangs/ goes to the reset handler at 0x450

Some interesting notes are that:

  • Both the Bootloader and Firmware are trying to reference the same 0x4004D040 address, which seems to correspond to Multiplexing Control for PORT-E. 
  • The first program is able to run this code fine, however the second code that tries to run through its same code fails

I've been digging through the GPIO muxing documentation in the RM, but can't find why just *reading* this register would fail after GPIO has been initialized. Any ideas here?

Labels (1)
Tags (3)
1 Solution
1,917 Views
allen_willson
NXP Employee
NXP Employee

Hello gearhead,

With ARM, clocks to the peripheral subsystems are normally gated OFF after reset. Accessing a peripheral that has no clock enabled will result in a hard fault, and the default startup code may make it appear near the reset handler or watchdog handler.

Please be sure to enable the clock group related to all peripherals you intend to access, in this case PORT_E.

See register PCC_PORTE.

-arw

View solution in original post

3 Replies
1,918 Views
allen_willson
NXP Employee
NXP Employee

Hello gearhead,

With ARM, clocks to the peripheral subsystems are normally gated OFF after reset. Accessing a peripheral that has no clock enabled will result in a hard fault, and the default startup code may make it appear near the reset handler or watchdog handler.

Please be sure to enable the clock group related to all peripherals you intend to access, in this case PORT_E.

See register PCC_PORTE.

-arw

1,917 Views
martijnetergo
Contributor I

Thank you, this helped solve my problem. For me, I had to manually call 

PCC_SetClockMode(PCC, PCC_PORTA_CLOCK, true);
PCC_SetClockMode(PCC, PCC_PORTB_CLOCK, true);
PCC_SetClockMode(PCC, PCC_PORTC_CLOCK, true);
PCC_SetClockMode(PCC, PCC_PORTD_CLOCK, true);
PCC_SetClockMode(PCC, PCC_PORTE_CLOCK, true);

after CLOCK_SYS_UpdateConfiguration and before PINS_DRV_Init, to make the program work.

1,917 Views
gearhead1107
Contributor IV

Thanks, Allen! I've definitely run into very similar issues with the original PE that didn't gate peripherals for you. I hadn't thought about the clocks not being enabled after reset - I'll dig in to confirm but I bet you're right!

0 Kudos