We use SIU_SRCR[SSR] to reset the processor: this works OK on 2N45H however does not appear to work on 3N45H.
The reference manual and errata don't mention anything, but I have two PCBs where the only hardware difference is the CPU mask and the PCB with the 3N45H does not reset correctly.
As an experiment I dragged out the debugger and tried to single step over the write to SSR:
On 2N45H the next instruction after the write to SSR is 0xfffffffc and execution continues as expected.
On 3N45H the P&E debugger reportes errors
Any ideas?
Hi, this is not known to me.
Have you tried to run standalone project without debugger? Does your 3N45H chip reset by SSR or not? I wonder if this can be caused by debugger..
I was running standalone and the PCB with the 3N45H would not reset via SSR but the PCB with 2N45H does. I then tried with the debugger and got the same behaviour.
After setting SIU_SRCR[SSR] the RSTOUT pin goes low and stays low indefinitely. I pulse the RESET pin low the CPU restarts, so this is not reset excalation. I can't find anything in the manual or errata to explain this.
Maybe it is the STCU but I haven't written any DCF records or software to enable this.
That's interesting. I have just test it and works fine on my side:
It is being periodically reset by SIU.SRCR.B.SSR = 1; running standalone without debugger and with debugger as well.
Used MCU is SPC5777CCMMO3 3N45H. I have checked various errata lists and I havent found anything what would be similar to your description.
Would you check attached code?
I tried flashing your elf image in our hardware but very early (eround 0x00800050) in __start() it goes to 0x00004900. Exception handler? Do you expect some other code to be flashed into those low addresses for your test? I haven't had time to analyse this. I'll pull a 3N45H from stock and try it in our 516DS.
However I am already setting SSR and it works as expected on 2N45H so maybe there is something unexpected regarding DCF records or some other CPU hardware we are using that has this odd side effect.
At least you have some to the same conclusion regarding errata, etc. I have patched a GPIO to RST as a short term hack so I don't delay some validation testting we have scheduled for the prerotduction hardware batch. I'll have to investigate this further later in the week.