Jun 20, 2014
06:20 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 20, 2014
06:20 AM
Hi,
I tried to upgrade firmware of a xmc4500-768 micro through the XMC4000_ASCBootloader/xmcload.exe PC program: everithing worked fine for three-four times.
In the last retry the flashing process has terminated for unknown reason while flashing a sector.
Now I can't access the micro controller anymore, neither through SWD nor through jtag.
Does anyone have any idea what's happening? I'm reasonably sure it's not an hardware problem.
Many thanks
Frank
I tried to upgrade firmware of a xmc4500-768 micro through the XMC4000_ASCBootloader/xmcload.exe PC program: everithing worked fine for three-four times.
In the last retry the flashing process has terminated for unknown reason while flashing a sector.
Now I can't access the micro controller anymore, neither through SWD nor through jtag.
Does anyone have any idea what's happening? I'm reasonably sure it's not an hardware problem.
Many thanks
Frank
- Tags:
- IFX
7 Replies
Not applicable
Jun 22, 2014
08:21 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 22, 2014
08:21 PM
Hi Frank,
Could it be the device has gone into read protection mode?
Is it still possible to established ASC BSL connection?
Could it be the device has gone into read protection mode?
Is it still possible to established ASC BSL connection?
Jun 25, 2014
05:15 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 25, 2014
05:15 AM
Hi Jackson,
this is what I found out:
I can reproduce the problem the following way:
1) Download through Dave a program into the microcontroller;
2) While debug is on, send a custom serial command to reboot the microcontroller into BSL mode:
SCU_GENERAL->STCON = 0x100; // STCON->SWCON = 1 (ASC boot mode)
SCU_RESET->RSTCLR = 0x01; // RSTCLR->RSCLR (Clear the reset status register)
if(SCU_GENERAL->STCON == 0x100){ // Reset the MCU if ASC boot mode is set
NVIC_SystemReset();
}
3) With xmc4500_loader download through serial line a new program.
If you execute the previous steps there are many probabilities to block the micro as I said.
- it is still possible to enter the ASC BSL, but the bsl stops programming on the same point: address 0x004000. It's a start address of a physical sector I see.
Then I recompiled the ASCLoader.hex from the Dave project, changing the function XMC4000_PFLASH_EraseSector:
* I commented the row // *((volatile unsigned long*)SectorAddr)=0x00000030; // erase logical sector
* I enabled the row *((unsigned long*)SectorAddr)=0x00000040; // erase physical sector
With this change the ASC bootloader works fine: after blocking the micro with steps 1-3, I can unblock it through the new bootloader.
I also noticed that memetool alwaus works fine: with either a "blocked " or unblocked micro while I don't understand why the jlink-lite doesn't work neither as jtag nor as SWD with a micro "blocked".
It seems to me that is a problem on chip erase: for same reasons the jlink cannot erase the chip correctly after it is blocked.
When I recompiled the ASCLoader.hex by choosing to erase physical sectors instead of logical sectors, what is the difference?
Thanks
-
this is what I found out:
I can reproduce the problem the following way:
1) Download through Dave a program into the microcontroller;
2) While debug is on, send a custom serial command to reboot the microcontroller into BSL mode:
SCU_GENERAL->STCON = 0x100; // STCON->SWCON = 1 (ASC boot mode)
SCU_RESET->RSTCLR = 0x01; // RSTCLR->RSCLR (Clear the reset status register)
if(SCU_GENERAL->STCON == 0x100){ // Reset the MCU if ASC boot mode is set
NVIC_SystemReset();
}
3) With xmc4500_loader download through serial line a new program.
If you execute the previous steps there are many probabilities to block the micro as I said.
- it is still possible to enter the ASC BSL, but the bsl stops programming on the same point: address 0x004000. It's a start address of a physical sector I see.
Then I recompiled the ASCLoader.hex from the Dave project, changing the function XMC4000_PFLASH_EraseSector:
* I commented the row // *((volatile unsigned long*)SectorAddr)=0x00000030; // erase logical sector
* I enabled the row *((unsigned long*)SectorAddr)=0x00000040; // erase physical sector
With this change the ASC bootloader works fine: after blocking the micro with steps 1-3, I can unblock it through the new bootloader.
I also noticed that memetool alwaus works fine: with either a "blocked " or unblocked micro while I don't understand why the jlink-lite doesn't work neither as jtag nor as SWD with a micro "blocked".
It seems to me that is a problem on chip erase: for same reasons the jlink cannot erase the chip correctly after it is blocked.
When I recompiled the ASCLoader.hex by choosing to erase physical sectors instead of logical sectors, what is the difference?
Thanks
-
Not applicable
Jun 30, 2014
02:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jun 30, 2014
02:05 AM
Hi Frank,
If you see the Reference Manual on the PFlash structure, you will find that Logical Sector S0 to S3 is under Physical Sector PS0 and Logical Sector S4 to S7 is under Physical Sector PS4.
A physical sector could divided into several logical sector where a logical sector is a group of word-lines of one physical sector.
If you see the Reference Manual on the PFlash structure, you will find that Logical Sector S0 to S3 is under Physical Sector PS0 and Logical Sector S4 to S7 is under Physical Sector PS4.
A physical sector could divided into several logical sector where a logical sector is a group of word-lines of one physical sector.
Jul 02, 2014
08:30 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 02, 2014
08:30 AM
It seems to me that the problem is in the EraseSector function of ASCloader project. When the micro is blocked the code block that checks if a sector is empty returns true even if that sector is not.
By removing that check and always forcing sector erase, erase works properly.
By removing that check and always forcing sector erase, erase works properly.
Not applicable
Jul 03, 2014
08:09 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 03, 2014
08:09 AM
Hello,
I wanted to run the Firmware loader but I can't find the sources on my computer
I have DAVE- 3.1.10; I follow the Tooling Guide V1.1 2013-11 so where I can find the sources
Thanks
Guy
I wanted to run the Firmware loader but I can't find the sources on my computer
I have DAVE- 3.1.10; I follow the Tooling Guide V1.1 2013-11 so where I can find the sources
Thanks
Guy
Not applicable
Jul 03, 2014
08:17 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 03, 2014
08:17 PM
Hi Guy,
Did you download the *.exe file for the tooling guide?
The source code is available inside.
Did you download the *.exe file for the tooling guide?
The source code is available inside.
Jul 03, 2014
11:20 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Jul 03, 2014
11:20 PM
Could this be related to http://http://www.infineonforums.com/threads/1035-XMC4500-768AB-FLASH-write-fail ?
We have had problems both erasing and programming FLASH (XMC4500) and had to ignore the FSR VER bit altogether as the reference manual suggests.
Had to make a change in the FLASH002.c DAVE APP.
I have not checked if latests version of Segger has changed their code after getting new info from Infineon.
When we had locked devices, the Segger was not able to unlock it.
Running code ignoring FSR VER fixed everything, and we have not had any problems since.
Cheers
We have had problems both erasing and programming FLASH (XMC4500) and had to ignore the FSR VER bit altogether as the reference manual suggests.
Had to make a change in the FLASH002.c DAVE APP.
I have not checked if latests version of Segger has changed their code after getting new info from Infineon.
When we had locked devices, the Segger was not able to unlock it.
Running code ignoring FSR VER fixed everything, and we have not had any problems since.
Cheers