Hello,
I am looking at a program I compiled for the R32C in a binary viewer.
I see that at 0xfffffffc the program points at 0, and I know that the offset is special as the "reset vector" according to the documentation.
My question is, how exactly does a typical firmqare execute on the R32C, what is the initial PC and the inital MCU start up in general.
I don't believe there is any general rule of thumb about where the R32C might begin executing code. As you mentioned the reset vector is fetched from 0xFFFFFFFC, this value could be any code flash memory location.
I am trying in my program to fetch the address stored at the reset vector and jump to it to trigger a reset.
It is not working, and instead the program freezes until i reconnect power.
Do you perhaps know why?
This is happening without a debugger attached.
Only jumping to the reset vector will not produce a reset with the hardware. What I would assume is happening is that the software is getting stuck somewhere expecting the hardware to be in a reset state but it is not.
I am not aware of a software reset mechanism on R32C, if this indeed not available then you would need to somehow force a hardware reset, either with some external circuit or you could have the watchdog timer enabled and tight-loop until that times-out.
What does jumping to the reset vector do then, exactly?
Re-starting execution of the code from reset vector only makes an attempt to re-start all of the software, but with all of the hardware used already initialized. This could present problems for some peripherals if the software does not make the assumption that the peripheral is already running.
What is it that you are trying to accomplish with a soft-reset?
I am trying to reboot my program entirely from scratch. I thought that accessing this vector would be a good choice.
With a debugger you might be able to figure out what doesn't work to accomplish this, but maybe a controlled manual shut-down of the peripherals and then a jump to the reset vector would suffice for your needs. Otherwise I would go with the watch-dog reset, it is simple yet effective.
Thank you very much man, could you please explain how exactly a watchdog reset works?
A WDT is just a timer that runs until it expires, and then resets the MCU, unless the timer counter is reset manually by software. The idea is that run-away software can be aborted if regular servicing of the WD is not performed.
If your WDT is already running, just tight-loop ("while (1) {}") which will cause a WDT reset eventually. If not already set, you will need to investigate the method to configure and start the timer, which is device dependent. Set up the timer to expire quickly, since no need to sit around waiting.
Here are a couple of app-notes on the topic for R32C:
And here is another useful app-note if you care to know whether the reset was due to WDT or other reset source:
I found this for one of the R32C devices (142/145 family), apparently there is a software reset mechanism:
That is super interesting, thank you so much!