Clock considerations after reset?

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

Clock considerations after reset?

Jump to solution
1,391 Views
gearhead1107
Contributor IV

I'm currently working to make my S32 reset from a "Firmware" application and start running a "Bootloader". The latest hurdle is that after a reset, the application gets hung up in "CLOCK_SYS_SetPccConfiguration" specifically in "PCC_SetPeripheralClockControl" for base 0x40065000

Edit: After stepping through the assembly, it looks like the problem is actually in PCC_SetClockMode() as it tries to disable the peripheral clock before setting control according to the config struct - the next instruction is where it croaks. The peripheral in this case is CORE_CLK, so it seems understandable that it would get irritated at this. What doesn't make sense is why this runs from initialization, but cannot be jumped to... /Edit

Since both the Bootloader and Firmware run just fine when flashed on their own, I'm assuming this is some issue with initializing the PCC after a reset. I'm looking at the Reference Manual, and it mostly states that when changing the PCC, the clock should be CGC gated and the module should be disabled by "MDIS" bit. For the most part it *looks* like the drivers try to disable the PCC before it sets the PCC configuration.

Is there any additional function I should call in Firmware before or after "SystemSoftwareReset" so that the PCC can be configured properly?

Labels (1)
Tags (4)
0 Kudos
1 Solution
1,074 Views
gearhead1107
Contributor IV

I found the issue that was (apparently) keeping my code from running... in short, the driver should never be trying to touch the CORE_CLK peripheral. What seems to have happened was that - after reset - the peripheral_clock_config_t struct was corrupted in RAM, so the first peripheral read was "0", interpreted as the core clock at the base of the PCC register. Bad news, since disabling it disables the core clock.

Normally I'd add this comment and mark as correct, but it's concerning that 

  1. Processor Expert does not give me a way to make the PCC settings const or "read only". This was the band-aid I applied to make sure my code runs, but it'll get blown away the next time I generate PE code. Should I file a ticket as a possible improvement to the PE tool?
  2. The clock_manager drivers do not check that a given index offset is valid. I see in S32K144_features.h that PCC_INVALID_INDEX is defined as the name mapping for core clock.. but SetPccConfiguration doesn't check for an invalid index before it tries to disable a peripheral. Possibly something to add for the next SDK release?

View solution in original post

0 Kudos
1 Reply
1,075 Views
gearhead1107
Contributor IV

I found the issue that was (apparently) keeping my code from running... in short, the driver should never be trying to touch the CORE_CLK peripheral. What seems to have happened was that - after reset - the peripheral_clock_config_t struct was corrupted in RAM, so the first peripheral read was "0", interpreted as the core clock at the base of the PCC register. Bad news, since disabling it disables the core clock.

Normally I'd add this comment and mark as correct, but it's concerning that 

  1. Processor Expert does not give me a way to make the PCC settings const or "read only". This was the band-aid I applied to make sure my code runs, but it'll get blown away the next time I generate PE code. Should I file a ticket as a possible improvement to the PE tool?
  2. The clock_manager drivers do not check that a given index offset is valid. I see in S32K144_features.h that PCC_INVALID_INDEX is defined as the name mapping for core clock.. but SetPccConfiguration doesn't check for an invalid index before it tries to disable a peripheral. Possibly something to add for the next SDK release?
0 Kudos