MSPM0G3507: FLASHDED issues

Hello Marcel,

The FLASHDED exception indicates an uncorrectable ECC error on the flash. Could you please give details on the TI flash API calls that are used to program the flash? Have you tried to reduce the problem to writing to a single flash block with the same calls so as to avoid the complexity of the investigation?

Best regards,
François.

Hello Francois,

Thank you for your reply!

Unfortunately, I cannot share some implementation details since the Flash APIs are implemented by the company which implemented the FlashBootloader for us. They are not using TI functions, but a colleague of mine compared the implementation and it told me they are very similar with TI ones.

Regarding your second question, I didn't try to writing a single flash block with the same calls, because right now I don't even know where the NMI exception is thrown. For example, if I go step by step with the debugger there are high chances that I will not get the FLASHDED. But if I run the SW without breakpoints, the exception is thrown. It's really hard to point out an interface which is causing the double error detect on FLASH region.

I would try to organize a debug session with the Vendor of FBL since they are knowing their code way better than me, and try to have a conclusion which interface is causing the ECC error..

Regarding DED error types, I also had a similar behaviour with SRAMDED and the only way to avoid that was moving SRAM Region to region where is not ECC or Parity checked.. That is also a workaround and not a proper solution, but I didn't find another way.. Regarding FLASH memory I cannot use the same type of workaround..

Can you try to use this code example to put the write or erase function in your current code to test at the same time?  Maybe it can help solve your question.

Hello,

Can you  please tell me where I can find this example project?

Then I will try to use the APIs from there.

Hi Marcel,

That's part of the MSPM0 SDK: [MSPM0_SDK_INSTALL_DIR]\examples\nortos\LP_MSPM0G3507\driverlib\flashctl_program_with_ecc

Best regards,
François.

Hello Francois,

Sorry, I didn't manage to try these interfaces until now. The most common moment when we are getting the FLASHDED error is when we read, not write or erase, that's why I didn't yet started to use the proposed solution.

I had a meeting with Vector Support Team and we saw that we have an ECC error (then FLASHDED) when we are trying to copy some data from FLASH to SRAM (unchecked), see below an example implementation with exact addresses where we get the FLASHDED:

// destination = 0x20204CD4 (unchecked SRAM), source = 0x1FFF8
void * CopyData(void * destination, const void * source)
{
    u8* localDest;
    const u8* localSrc;
    u8 i;
    
    localDest = (u8 *)destination;
    localSrc = (const u8 *)source;
        //4 is hardcoded number, just for an example
        for(i = 0; i < 4; i++)
        {
            localDest[i] = localSrc[i];
        }
    return destination;
}

So we get the FLASHDED where localDest[i] takes the value of localSource[i].

Can you tell us why we even get a FLASHDED here? Can it be related to the memory addresses where we read and write?

Also what it is interesting, is that this is not a permanent issue, there are moments when this interface is working as expected. In my opinion, is not an implementation issue, but maybe some timing-related, or memory related?

Please let me know if you have some suggestions on what we are doing wrong here..

If you want to have a deeper look, we can have a debug session and see if we can find the issue.

Thank you in advance!

Can you disable the flash write first. I want to double check if the problem only lies on the Flash read and write to SRAM. The FLASHDED means the readed data from Flash have a non-correctable ECC error. I want to check if the problem only happens when you keep reading or happens when you wirte and read.

It will be good if you can share an small example code which can create this problem.

Why your start address is 0x1FFF8? It is the end of the flash.

Hello,

Thank you for your response! I will try to answer below to your questions.

"Can you disable the flash write first."

- I set a breakpoint to the Read, Erase and Write interfaces to see which of them causes the FLASHDED. The breakpoints on Erase  and Write  are not hit at this phase. The Breakpoint in Read interface is hit sometimes 3 or 4 times (first times read the first 8 bytes of presence pattern starting with 0x1FFE0, second time reads the next 8 bytes starting with 0x1FFE8, third time reads the next 8 bytes starting with 0x1FFF0, and the last time it should read the last 8 bytes of Presence pattern starting with 0x1FFF8). Why I say that the breakpoint is hit 3-4 times? Because most of the times the FLASHDED is thrown at the last read of PP (4th call of Read interface), but sometimes FLASHDED is thrown at the 3rd call of Read interface.

Now looking to the picture with memory organization I see that Flash ends at 0x1FFF8, not 0x1FFFF as we and also Vector thought. Basically, in the  current configuration we have presence pattern placed from 0x1FFE0 up to 0x1FFFF, which indeed could cause some FLASHDED. 
I will address this further to Vector and I will let you know the result. 

Can you also provide me a link where I can get the reference manual which you are using? We are using a different version and I don't have such information inside that Flash ends at 0x1FFF8..

Thank you in advance!

Here is my reference:https://www.ti.com/lit/ds/symlink/mspm0g3507.pdf

Section 8.7. I think for the useable memory range, you should always refer to the datasheet not TRM.

I will check with team what happens if use the additional 8 bit.

In MSPM0G implementation, one word (8bytes) will be prefetched into cache, when flash reading, in order to make CPU to work fast. If CPU try to read the last 8 bytes, that will cause a fault since the prefetch logic tries to read an invalid address 0x1FFFF+8.  

So I would suggest you to not use above 0x1FFF8.

Hello,

Thank you for your response!

I understand that we should memory above 0x1FFF8, but then we cannot use the last sector of flash memory, right?

Since minimum erase resolution is 1KB then memory area 0x1FC00-0x1FFF8 we can not properly use since the size of it if 0x3F8 instead of 0x400 (1024 bytes). Can you confirm this?

Yes, I am confirm.

Hello,

Thank you for your answers!

Indeed moving the presence pattern starting from 0x1FBE0 up to 0x1FBFF fixes the issues with FLASHDED during Erase and Check Memory routines.

However, I will not close the ticket yet since sometimes I get FLASHDED error during the data transfer which doesn't involve the limits of FLASH memory. I will discuss this with Vector and try to find what is the reason. I will keep  you updated. This issue is not that easy to find because 0x36 UDS Service is repetitive and in most of cases I get the Flashded after 39kb transferred so using some SW breakpoints is not feasible. Let's see what Vector says about this, and I will let you know if we have further questions.

Thank you!

Sorry, I miss understand your words. You can use the last sector, but we don't suggest to use the last 8 bytes of the last sector because of the CPU perfech function. That means for the last sector you can use 0x1FC00-0x1FFF8.

Another possiblity you will meet FLASHDED when programming is that you use "DL_FlashCTL_programMemory64()" instead of "DL_FlashCTL_programMemoryFromRAM64WithECCGenerated()". 

Hello,

I got the request from our Technical Project Leader to ask you to add this information (that last 8 bytes are not usable) to the TRM (technical reference manual) because it is a really important information, and in our opinion it shall also be present in TRM, not only the DataSheet.

Can you confirm when you forward this request to the TRM responsible and let me know if it will be updated or not?

Thank you!

Thank you for the reminder. I will create a ticket internally. It will be updated in the following 1 or 2 TRM version.

Hello Eason: I have the same issue. I also use the last sector, and occur FLASHED issue when we read last 16Bytes. Since minimum erase resolution is 1KB then memory area 0x1FC00-0x1FFF8 ,Can the last sector erase  properly  since the size of it if 0x3F8 instead of 0x400 (1024 bytes). Can you confirm this?

Hello Marcel, I have the same issue with you. Do you solve this issue? 

Hi Lifang,

Yes, you can erase the last sector with 0x1FC00-0x1FFFF. But you can't use CPU to read the data across (0x1FFF8 to 0x1FFFF), because the one word (8bytes) always will be prefetched into cache.

Eason