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?
Solved! Go to Solution.
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
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