C40_Ip_MainInterfaceWrite strange behavior during consecutives Flash Program

[ziomocci]

Hi all,

As usual, we need to performs multiple Flash Program operation during, for eg, ECU firmware updates.

Below the interface

sint16 FLASH_Program (uint32 address, uint32 size, uint8 * source)
{
sint16 res = 0;
C40_Ip_VirtualSectorsType virtualSector = 0u;
C40_Ip_StatusType C40Status = STATUS_C40_IP_SUCCESS;

    /* Get virtual Sector number from address */
    virtualSector = C40_Ip_GetSectorNumberFromAddress(address);

    /****************************************************/
    /*      USE MAIN INTERFACES FOR FLASH JOBS          */
    /****************************************************/

    /* Unlock sector if needed */
    if (STATUS_C40_IP_SECTOR_PROTECTED == C40_Ip_GetLock(virtualSector))
    {
        C40Status = C40_Ip_ClearLock(virtualSector, FLS_MASTER_ID);
        if(STATUS_C40_IP_SUCCESS != C40Status)
        {
            return(sint16)C40Status;
        }
    }

    /* Write data */
    C40Status = C40_Ip_MainInterfaceWrite(address,size,source,FLS_MASTER_ID);
    if(STATUS_C40_IP_SUCCESS != C40Status)
    {
        return(sint16)C40Status;
    }
    do
    {
        C40Status = C40_Ip_MainInterfaceWriteStatus();
    }
    while (STATUS_C40_IP_BUSY == C40Status);


    /* Re-lock sector after program operation */
    C40Status = C40_Ip_SetLock(virtualSector,FLS_MASTER_ID);
    if(STATUS_C40_IP_SUCCESS != C40Status)
    {
        return(sint16)C40Status;
    }

    return(res);
}

  After putting the function call inside a for(;;) in the main translation unit, I try to update the address 0x500000, w/o any problem

ziomocci_0-1666198391330.png

Calling the API a second time on address 0x500070 with the same input source, this is the result

ziomocci_1-1666198511449.png

It seems like the C40 driver does not write four lines of Flash.

Then I use the address 0x5000A0, and the driver works as expected

ziomocci_2-1666198728621.png

I have repeated multiple tests using different address, and sometimes not all the flash lines are programmed as expected. In the picture below you could find the flash layout after 80 bytes programming on 0x500000/500080/500100/500160 

ziomocci_3-1666199417436.png

All suggestions would be very appreciated!

B.R.

Andrea

[ziomocci]

Hi @danielmartynek ,

Even if for our scopes we cannot consider the flash not-cacheable, I have tested also your proposal number 2), but problem persist with the same effects.

[danielmartynek]

Hi @ziomocci,

This is caused by the cache.

There are two options:

1.

Call the API function Cache_Ip_InvalidateByAddr(CACHE_IP_DATA, TargetAddress, 32) after the programming is completed or before reading back the data.

2.

Disable the Flash area cache in MPU settings.
In the system.c file, function SystemInit(), the code rasr[2]=0x060B002BUL is changed to be rasr[2]=0x0608002BUL
This modification changes the Flash region to non-cacheable.

Regards,

Daniel

[ziomocci]

Hi @danielmartynek,

For project configuration reason we can not consider the Flash not-cachable, so that your proposal number 2) is not applicable.

I would like to remember that Cache_Ip_InvalidateByAddr() is defined as static inline in Cache_Ip.h 

ziomocci_1-1666279555696.png

but I can call it in other translation unit, a bit strange.

Anyway, I have put the function call after the end of programming procedure

ziomocci_2-1666279717467.png

and then I have repeated a few tests, below the result.

Demo works as expected considering default values

ziomocci_6-1666280956587.png

unfortunately, I can not say the same when I change the FLS_SECTOR_ADDR

ziomocci_5-1666280691674.png

If I change both FLS_SECTOR_ADDR and FLS_BUF_SIZE the scenario is still errored

ziomocci_8-1666281953032.png

So, am I calling the cache invalidation in the wrong point or with wrong parameters?

I have also read these lines in the RTD_FLS_UM

ziomocci_9-1666282102654.png

Is it a driver implementation or actually a Flash Hardware limitation?

B.R.

Andrea

[danielmartynek]

Hello Andrea,

Can you share the whole project or a test project that can replicate the issue so that I can test it on my side?

Based on the error mesage though, it seems like the programming fails (program verify).

Is the sector erased successfully?

Thanks,

Daniel

[ziomocci]

Hi @danielmartynek ,

 Attached you could find the project.

The two difference with the demo are:

ziomocci_1-1666606501505.png

1. C40status is not local in main(), but global for watching with OpenSDA debugger.
2. FLS_SECTOR_ADDRESS for trying to write Flash at 0x00600060ziomocci_2-1666606671813.png

Looking forward to your feedback,

B.R.

Andrea

[ziomocci]

Hi @danielmartynek ,

 do you have any good news for me about the behavior of the MainInterfaceWrite?

Thank you in advance,

Andrea

[danielmartynek]

Hello @ziomocci,

I'm very sorry for the delay.

I was out of office for a weak and my colleagues were busy.

I'm testing it now.

BR, Daniel

[danielmartynek · Accepted solution]

Hello Andrea,

There is a bug in RTD 2.0.0 and 2.0.1 that has been fixed in RTD 3.0.0.

Have a look at Section 20.5.1.2 in the RM rev.4.

"Up to four pages can be programmed at once on a quad-page boundary. The program operation
consists of the following sequence of events:"

Section 20.2.1

"The embedded flash memory is addressable by page (256 bits) for read operation and double-word(s)
and page and quad page for program operations."

Up to four pages (maximum 128-byte of the program data buffer) can be programmed at once on a quad-page boundary (aligned with 128-byte as well).

This means the data to be written must fall within a quad-page.

In the new release RTD 3.0.0, there is a condition check for Address Offset + Length <= C40_DATA_SIZE_BYTES_U32 (128 Bytes).

I hope it explains it,

Regards,

Daniel

[ziomocci]

Hi @danielmartynek,

So there was a bug...a big bug form my POV.

Anyway, it seems like we have to use the RTD version 3.0.

But how could I retrieve it? I have installed S32DS Version: 3.4 Build id: 201217 (Update 3) in my laptop and these are the available packages

ziomocci_0-1667403802435.png

RTD ver.3.0 for S32K3 target is not listed.

Same problem if I take a look to the download page from NXP site

ziomocci_1-1667404172470.png

Sw list appears a bit confused I am sorry.

So, could you give me a valid download link for last version of S32K3xx C40 Ip Real Time Drivers?

Until this moment I cannot give you any feedback.

Last but not least, we are testing also other RTDs (SPI, EMIOS, etc) --> do we have to updated all peripherals RTD?

B.R.

Andrea

[danielmartynek]

Hello Andrea,

The 3.0.0 version has not been released yet.

You can use the version you are using now, but you need to write the flash with 0x10, 0x20 or 0x40 writes.

Regards,

Daniel

[ziomocci]

Hi @danielmartynek,

 So we have to wait for RTD release. I hope it happens as soon as posible, you could understand that flash driver correct working is mandatory for ECU reprogrammings, usually one of the first features required by car/motorycles/etc OEMs.

To be honest there was another issue, but maybe it is better to wait for new RTDs and open new discussion, if needed.

B.R.

Andrea

[danielmartynek]

I see the next release scheduled for Q1/23.

But even with the new release, you would need to properly align and size each of the writes, otherwise the new condition in the driver would return an error. So, this is something you can do with this release too.

BR, Daniel