XMC4500 Flash Sector S0-S4 write is an issue even with no protection enabled

Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob
User13084
Level 1
Level 1
Hi,

I am developing a bootloader on XMC4500 controller via UART communication interface.
These are following issues faced:
1.I am finding problems with respect to Flash write onto specific sectors.
According to the data sheet, initial 3kb of flash is user configurable block and can be password protected for write and erase operation.
But the strange thing is without any passowrd or normal protection mechanism, I am unable to write to 3rd or 4th sector (Sector 2, Sector 3 as per data sheet)in Flash.
After 64kb of flash, that means from 5th sector onwards (Sector4 as per data sheet) write operation is possible.
In DAVE example application on Flash, initial four sectors of Flash is not being addressed.
Is there any specific reason for this behaviour ?

2.If initial four sectors cannot be written or if it is locked by debugger when no protection is enabled(assumption made),
then an attempt to flash a corrupt image file onto first 2 sectors of Flash functioned.
How can this be possible?

3.After many flash erase and write, does the controller stops working and no more flashing mechanism can be performed?
Because, after flashing many times, the XMC4500 relax kit has stopped working.

Could anyone please explain the reason behind this issue? It is a critical issue and any help would be appreciated 🙂
0 Likes
11 Replies
User12775
Level 5
Level 5
First solution authored First like received
Why not using the built-in BROM0?

3. How many times have you erased/flashed it?
According to the datasheet, the 64Kbyte sectors have an endurance of 10000 cycles.
0 Likes
User13084
Level 1
Level 1
Hello aurixuser,

Built in BROM cannot be used because it is a bootloader development for specific test system. The requirement is to update the software routines into numerous devices.
Hence, separate bootloader is being developed and the memory space after BROM has been used. The sectors after BROM is dedicated for the developed bootloader.
The following sectors is used for CRC storage to validate and later sectors to store the application. Therfore, all the sectors has to be accessed and written.
Thus, I found the issue of writing into first few sectors.

3. I dont have the actual count but, I dont think I have crossed 10000 cycles.
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi,

Did you look to the AP201609 - XMC4000 firmware update via SDcard and the associated code?
Also at the Example Projects for DAVE™ Apps you can find USBH and USBD firmware upgrade examples.

Which software are you using to erase the flash sectors? By default, there is no restriction on which sectors you can erase/write.

Regards,
Jesus
0 Likes
User13084
Level 1
Level 1
Hi Jferreira,

I have looked into the ASC Bootloader of Infineon and also Firmware update via SDcard.
But, the Bootloader development here requires a self initated update through serial communication.
It is used for a stress test inside climate chamber. It is necessary to have the built in bootloader and then start with update of the software routines.
The hardware with XMC controller use CAN, UART and hence it cannot be generalised to any interface.
Also, it is not possible to use the boot modes provided as this has to be done after the built in boot.
Therefore, the firmware update via SDcard or ASC bootloader cannot be used.
Hence, I developed a customized bootloader. But, the mentioned codes were referred in the process.

Software used to erase flash sectors : DAVE4 and Flash command sequence according to the XMC datasheet. I also used DAVE FLASH inbuilt APP CODE .
As, you said there is no restriction and things should work. But, can you please try to reproduce the issue. Try to write some data into sector3 with the start address of 0x0C00C000 .
Atleast a data of 1 page without any protection. This does not work. But sector 4 onwards is possible. This was tested here by 2 of my colleagues here.
Could you please see what is the issue with respect to this? We have here tried all possibilities here and I think reproducing the issue would give more insight into the problem.

Thanks & regards,
Arpitha
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi Arpitha,

I could reproduce your issue and actually is not an issue but an artifact of the debugger.
I used the following code:

#include 

int main(void)
{

uint32_t page[XMC_FLASH_WORDS_PER_PAGE];

for (int i = 0; i < XMC_FLASH_WORDS_PER_PAGE; ++i)
{
page = i;
}

XMC_FLASH_EraseSector(XMC_FLASH_SECTOR_3);
XMC_FLASH_ProgramPage(XMC_FLASH_SECTOR_3, page);

/* Placeholder for user application code. The while loop below can be replaced with user application code. */
while(1U)
{

}
}


If I run this program using the debugger to download the code I can see in the memory window that the programming is not as expected.

2582.attach

But if I launch a separate JLink commander, attaching to the running target (for that select CORTEX-M4 as device) and check the sector 3 contents they are as expected

2583.attach

Unfortunately I do not have an explanation why the debugger window is not showing the correct contents (my guess some kind of optimization introduced by Segger, where they avoid reading from flash memory since they know the contents they flashed).
We will contact Segger, but in the meantime there is no issue with the programming.

Regards,
Jesus
0 Likes
User13084
Level 1
Level 1
Hi Jesus,

Thank you so much for your time . It is really appreciable that you reproduced the issue and found the actual reason behind it. This is really helpful and a good information to proceed in my project.
Now, I can save the memory regions as I know, writing to any sectors is not a problem 🙂

The debugger has posed few issues. As in this case and my colleagues here had another problem with old version of debugger which bricked the controller.
It would be good if Segger provides a solution for this.

Thanks & regards,
Arpitha
0 Likes
User13084
Level 1
Level 1
Hi Jesus,
There is an interesting finding regarding this issue. You mentioned it to be an artifact of the debugger, as the sectors are written and they are just not visible in the memory window of DAVE.
But , I perform a check of CRC values from the written sectors. I now tried to write to sector 3 and read back the value .And based on the read value, then enter into led blinking function.
I did this in debug mode and release mode. But, no success. I tried to read the value into a variable and every time , it is zero. Hence, I cannot use sector 0-4 to write or to read back the values.
It does not look like artifact but as a bug to me. I thought of sharing this information so that, may be there would be some solution for this issue.

Thanks & reagrds,
Arpitha
0 Likes
User13084
Level 1
Level 1
Hi Jesus,

Thank you for your time and for the code.

I tested your code to write and read sector 3, it works absolutely fine. And also, I tried to do the same in my project and I could successfully read the sector 3 values from the variable.
But, the issue does not end here. If I write into the sector 3 and then read it after the write operation then, I can read from the variable .
In my project, I write the CRC values into the sector in the initial flashing. Later, again flash the controller and without performing any write operation , read the sectors for CRC values at the beginning .
Here, the check fails with 1st four sectors and works fine with sector 5 onwards.
I tried the same with your code separately to test the flash. I see the same issue. Writing to sector 4 in 1st flash and reading it works fine.
Then, re-flash the controller and check the sectors without any write operation works fine for sector 4 but not for sector 3.
Hence, I was seeing the issue of reading data from sector 3 until now. Wherein, I never tried to read the variable immediately after the write operation.
It is an interesting finding and a strange issue.

Thank you once again for your assistance,

Kind regards,
Arpitha
0 Likes
User13084
Level 1
Level 1
Hi Jesus,

Thank you for your time and for the code.

I tested your code to write and read sector 3, it works absolutely fine. And also, I tried to do the same in my project and I could successfully read the sector 3 values from the variable.
But, the issue does not end here. If I write into the sector 3 and then read it after the write operation then, I can read from the variable .
In my project, I write the CRC values into the sector in the initial flashing. Later, again flash the controller and without performing any write operation , read the sectors for CRC values at the beginning .
Here, the check fails with 1st four sectors and works fine with sector 5 onwards.
I tried the same with your code separately to test the flash. I see the same issue. Writing to sector 4 in 1st flash and reading it works fine.
Then, re-flash the controller and check the sectors without any write operation works fine for sector 4 but not for sector 3.
Hence, I was seeing the issue of reading data from sector 3 until now. Wherein, I never tried to read the variable immediately after the write operation.
It is an interesting finding and a strange issue.

Thank you once again for your assistance,

Kind regards,
Arpitha
0 Likes
jferreira
Employee
Employee
10 sign-ins 5 sign-ins First like received
Hi Arpitha,

With the following code, I can see that the correct values are programmed.

#include 

int main(void)
{

uint32_t page[XMC_FLASH_WORDS_PER_PAGE];

for (int i = 0; i < XMC_FLASH_WORDS_PER_PAGE; ++i)
{
page = i;
}

XMC_FLASH_EraseSector(XMC_FLASH_SECTOR_3);
XMC_FLASH_ProgramPage(XMC_FLASH_SECTOR_3, page);

for (int i = 0; i < XMC_FLASH_WORDS_PER_PAGE; ++i)
{
uint32_t temp = *(XMC_FLASH_SECTOR_3 + i);
if (page != temp)
{
__BKPT(0);
}
}

/* Placeholder for user application code. The while loop below can be replaced with user application code. */
while(1U)
{

}
}


Regards,
Jesus
0 Likes
User13084
Level 1
Level 1
Hi Jesus,

As you mentioned the debugger erases the logical sectors 0-3 every time while flashing then I cannot make use of these sectors to store the data.
Yes, this could be the reason, I see the issue while reading back these sectors.

Thank you for all your assistance.

Kind regards,
Arpitha
0 Likes