Mar 22, 2017
09:41 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 22, 2017
09:41 AM
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 🙂
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 🙂
- Tags:
- IFX
11 Replies
Mar 23, 2017
03:27 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 23, 2017
03:27 AM
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.
3. How many times have you erased/flashed it?
According to the datasheet, the 64Kbyte sectors have an endurance of 10000 cycles.
Mar 27, 2017
05:19 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 27, 2017
05:19 AM
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.
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.
Mar 28, 2017
06:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 28, 2017
06:34 AM
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
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
Mar 30, 2017
07:11 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 30, 2017
07:11 AM
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
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
Mar 31, 2017
08:16 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Mar 31, 2017
08:16 AM
Hi Arpitha,
I could reproduce your issue and actually is not an issue but an artifact of the debugger.
I used the following code:
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.
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
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
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.
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
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
Apr 03, 2017
04:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 03, 2017
04:31 AM
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
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
Apr 04, 2017
01:08 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 04, 2017
01:08 AM
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
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
Apr 04, 2017
05:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 04, 2017
05:31 AM
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
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
Apr 04, 2017
05:36 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 04, 2017
05:36 AM
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
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
Apr 05, 2017
01:50 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 05, 2017
01:50 AM
Hi Arpitha,
With the following code, I can see that the correct values are programmed.
Regards,
Jesus
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
Apr 18, 2017
04:34 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apr 18, 2017
04:34 AM
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
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