Flash Initialization Failure MPC5748G

[vinciane_bronne]

Hello,

I'm working on making a bootloader on MPC5748G (0N78S). The steps are:

- application updates a value in RAM then resets using SystemSoftwareReset function

- we always start with the bootloader, so when it reads the value in RAM, it knows that an update is requested, else if a valid application exists, it jumps to the application else we stays in the bootloader

The problem is I have a Flash Initialization Failure on SWT0 after the software reset, so it becomes a destructive reset, my value in RAM is suppressed and I go again directly in my application.

I can reproduce the issue with the simple hello_world project, where I added the detection of a push button that provokes the call to the SystemSoftwareReset function. Then the F_SWT0_RES bit in MC_RGM is raised.

I tested on MPC5748G devkit and mainboard, same result (attachment configured for MB).

I work with S32DS Version: 2017.R1 Build id: 171018, with SDK S32_SDK_S32PA_RTM_3.0.0

I tried to read the MC_RGM in the start-up to see when it is updated but I locked the micro... My asm knowledge is very poor !

Could you give me some tips to understand the issue and find a correction ?

Thank you in advance

Vinciane

[petervlna]

Hello,

The problem is I have a Flash Initialization Failure on SWT0 after the software reset, so it becomes a destructive reset, my value in RAM is suppressed and I go again directly in my application

There can be no flash initialization failure on SWT0 as SWT0 does not have flash.

I can reproduce the issue with the simple hello_world project, where I added the detection of a push button that provokes the call to the SystemSoftwareReset function. Then the F_SWT0_RES bit in MC_RGM is raised.

The fault you are seeing is either SWT_0 timeout reset reaction or failure in HW flash module initialization (which is guarded by SWT_0) performed during reset phase1.

You can exclude Flash initialization failure during reset phase.(it is very hard to get this failure even with incorrect voltages on flash)

So what you are seeing is simple SWT_0 timeout reset.

To understand the issue please see following:

The device is by default (from NXP factory) programmed by active SWT_0 which timeout is 20ms. By default there is enabled reset reaction on this timeout and in addition there is also reset escalation enabled to 15 consecutive resets.

What you have to do in your code is to service/disable the SWT_0 in first 20ms after reset event. Have in mind that 20ms is quite fast and your application wont reach main.(maybe in case you wrote startup assemble and optimize it)

Simply add watchdog disable in assembly to your startup, for example:

#/* SWT_0.SR.R = 0xc520; */
e_lis r12,-0x3FB # r12,-66781184
e_li r0,0xC520 # r0,50464
e_li r11,0xD928 # r11,55592
#/* SWT_0.SR.R = 0xd928; */
e_stw r0,0x10(r12) # r0,16(r12)
e_lis r0,-0x1000 # r0,-16777216
e_stw r11,0x10(r12) # r11,16(r12)
#/* SWT_0.CR.R = 0xFF00010A; */
e_add16i r0,r0,0x10A # r0,r0,266
e_stw r0,0x0(r12) # r0,0(r12)

best regards,

Peter

[vinciane_bronne]

Hello Peter,

Thank you for your reply.

Actually, there was already a similar code in the start-up (see below), I've just changed the value set in the SWT_0.CR.R to 0xFF00010A instead of 0xFF000102, but I still have the F_SWT0_RES in the MC_RGM_DES register.

Anyway, I made a test to print the value of the MC_RGM_DES register on the console to see it independantly of the debugger, and like that, the bit is not raised !

So the debugger should be responsible to slow the µc and so the F_SWT0_RES appears.

Could any configuration in the debugger be modified to avoid that ?

Regards

Vinciane

Code to disable the watchdog in my start-up :

e_lis r4, SWT_BASE_ADDR@h ;# Initialize the base address of SWT_0
e_or2i r4, SWT_BASE_ADDR@l

e_li r5, SWT_COUNT@l
mtctr r5 ;# Move to counter number of SWT instances

disable_swt:
e_li r3, 0xC520
e_stw r3, 0x10(r4) ;# Write the watchdog unlock value 0xc520

e_li r3, 0xD928
e_stw r3, 0x10(r4) ;# Write the watchdog unlock value 0xD928

e_lis r3, 0xFF00
e_or2i r3, 0x010A
e_stw r3, 0(r4) ;# Write 0xFF00010A in SWT_x_CR

e_addi r4,r4, 0x4000 ;# Increase the pointer to the next instance of SWT
e_bdnz disable_swt ;# Loop for all instance of SWT