SW Reset MPC5775E from App to Boot

[latheef]

Further to the topic Solved: Re: MPC5775E Flash Programming exception - NXP Community

Now when I try to perform the SW Reset from the App it actually resets but instead of going to the Boot it actually come to App itself. @lukaszadrapa please let me know if I am missing anything trivial? 

void SystemSoftwareReset(void)
{
/* Set SSR bit to generate a software internal system reset */
SIU->SRCR |= SIU_SRCR_SSR_MASK;
}

[latheef]

I read through the AN5191: MPC5777C Software Initialization and Optimization – Application Note (nxp.com)

And here it says that for non SW reset the BAM will search for the RCHW in the flash sector as per the priority and execute the next word. I have the valid RCHW in 0x08000000 (for boot) and in 0x00840000(for app). But the document doesnt say where will be code run from after Software reset?

Any idea guys? @lukaszadrapa please help?

[lukaszadrapa]

Hi @latheef 

I believe the application note should say "except for software external reset" which just asserts RSTOUT but not internal reset.Moreover, 0x840000 is not bootable location, so it looks just like some SW issue. Normal software reset triggered by SSR will follow the same procedure when searching for valid RCHW.

Regards,

Lukas

[latheef]

@lukaszadrapa Now I have issue with calculating the Code CRC32 from 0x00840000u with the size 0x1BFFFCu (end of the code flash) and comparing with  the App CODE CRC32 which I inserted @0x009FFFFC in the App Hex. 

I used crc table method (my own implementation) to calculate the CRC32 for  byte size 0x1BFFFCu and it takes around 980ms to finish the calculation. This time is not acceptable, but it matches to the CRC inserted in the Hex.

Now I tried to use the CRC PE component and see if it gives the CRC32 in reasonable time, but now I have stumbled across below issue:

1)  CRC32 from the CRC PE Component takes around 500ms now(half the time). This is not good enough, how can I make my MCU startup time reasonable?

2) The CRC32 calculated by the CRC Module is not matching? What config changes I need to make to match?

I checked the CRC32 four bytes  0x12,0x34,0x56,0x78 and the crc from CRC module gives 0xe68f6fad while the expected  crc1 (by my routine) is 0x4a090e98 which also matches the online crc32 calculator.

[lukaszadrapa]

Hi,

1. To speed it up, it's important to have the cache enabled or force the loop to RAM. Another option is to use DMA - not sure if it improves the execution time but you can do something different at the same time, at least.
I would also try to temporarily enable data prefetching in PFCR1/PFCR2 register. This could also help. You can see that in mentioned AN5191.

2. Comparing the numbers, you should check Read Transpose and Complement Checksum options.

Regards,
Lukas

[latheef]

@lukaszadrapa The CRC now matches with below configuration

Enabling the Cache brings down the time 500+ms to 185ms and enabling data prefetching further down to 178ms. Using my CRC Routine (instead of CRC Module) bring it down to 93ms. 

I tried using the DMA  with CRC Module inline with your code  Example MPC5748G CRC32 GHS614 - NXP Community

It actually increases the time to 184ms.  What could be the reason for that?

On you comment something different at sametime using DMA. Did you mean to use three instance of CRC module and split the CRC calculation to three blocks but then how the value will match to one inserted in the App hex? Any clue please?

[latheef]

@lukaszadrapaI found this tenchnique to split the CRC -> CRC(a XOR b) = CRC(a) XOR CRC(b).

When I split into two chunk  using below code, the time comes down from 185ms to 90ms. To improve it further I thought of splitting into 4 chunk and use 3 DMA Channel (Channel0 to 2) in parallel with three instance of CRC module and last one chunk using my CRC routine but this increases the time to 140ms now. So it seems these DMA channel cannot be used in parallel. Is there anyway I can achieve this concurrency?

transferConfig.minorByteTransferCount = APPCODE_HALF_SIZE;

EDMA_DRV_ConfigLoopTransfer(EDMA_CHN0_NUMBER, &transferConfig);
EDMA_DRV_TriggerSwRequest(EDMA_CHN0_NUMBER);

CRC_DRV_WriteData(INST_CRC2, (uint8_t*)APPCODE_START+APPCODE_HALF_SIZE, APPCODE_HALF_SIZE);
uint32_t crc1 = CRC_DRV_GetCrcResult(INST_CRC2);

// Wait for DMA Done interrupt

while(g_transferCompleteIteration == 0)

[lukaszadrapa]

Hi @latheef 

the DMA module can't execute the channels in parallel. The requests are executed one by one based on priorities. I was thinking about one more option - to calculate part of CRC by core and part by DMA in parallel but there would be probably problem with flash reads (reading from two different spaces at the same time could affect the data prefetching and read buffer on flash -> resulting in higher access time). But maybe you can test that. I have no other ideas.

Regards,

Lukas