bootloader F28M36 - ARM M3

Andreas,

There are some differences in the memory map between the Stellaris part and the Concerto part. Also on the F28M36x we don;t have Flash API in ROM. We do have ROM loaders for booting from Ethernet and they help load application code onto device RAM. You can send this application using LM Flash programmer as shown in the boot ROM chapter of the device TRM.

Now that is basic support to help customer get some application onto the device. Same is the case with any other peripheral boot loader on this device. Please check Uniflash as it supports flashing the chip over UART. But if you want to implement your own solution and have it working over Ethernet below are the things you will have to do.

You will have to come up with a flash programming kernel that takes/parses the incoming data from EMAC and programs the Flash. We have Flash programming examples for the device in controlSuite. Now for parsing the EMAC data you can use bootp or other file transfer protocols in the kernel.

One challenging part here would be that you should be able to download all of this kernel onto RAM and run from RAM. This kernel will take over the Ethernet port from ROM loaders and starts receiving the application data and flashed the data.


Hope this helps.

Best Regards
Santosh Athuru

The Stellarisware examples are still available in the below link, so you can take a look at the ethernet boot loader code to extract the packet processing protocol code and include them into the kernel.

http://www.ti.com/tool/SW-LM3S


Best Regards
Santosh Athuru

Hi Santosh,

thanks for the information. I will have a look on that, maybe it helps.

As for now I already implemented a driver which can wirte to the flash of the device and I also started to develop an application part which is executed from RAM already.

I'm currently testing this application so I want to write some test data (e.g. 0x5A5A5A5A) to the whole flash. But when I start this application after a short time it jumps to the FaultISR() of the demo project.

Do you know what can be the reason that this happens? It was already possible that I wrote to the first adress 0x200000 and I locked the flash accidentally but this is no problem, I know how to unlock it again.

Can it have something to do with the watchdog? When I tried to simply comment out the watchdog initialization the program was not working.

The most important question is the FaultISR() which is mapped to the Hard-Fault interrupt vector according to the manual.

thanks in advance

Andreas

Andreas,

yeah, try to avoid programming password locations and userOTP regions for now. Are you programming ECC as well? The Fault ISR can happen for couple of reasons and one is uncorrectable error from flash which will happen if no ECC is programmed but the location is read with ECC enabled.

The other reason could be that you might still have some functions linked to flash which got re-programmed and the CPU is fetching illegal opcode? WatchDOG can be disabled from your start up code before you enter main or in your main(), try to use the driverlib watchdog disable function instead of just commenting out the initialization and see if that works.

Hope this helps.

Best Regards

Santosh Athuru

Hi Santosh,

yes ECC is programmed as well. I checked the functions which may have been used from flash and I set the WatchdogReset function now also to flash. At the moment it works for 100 write cycles, where in one write cycle 16 bytes are written. Aftre that the program tries to jump back to the calling point (which is in a memory region where nothing was overwritten) but at the moment of jumping back it chrashes and jumps to the faultISR.
But I will check further on if there are some functions, which are still not in RAM.
Which watchdog disable function do you mean? I only found this function: void WatchdogResetDisable(unsigned long ulBase)
which is called like a disable function... but no real WatchdogDisable (like the WatchdogEnable)

kind regards
Andreas

Andreas,
actually it is in sysctl.c, try SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG0) and SysCtlPeripheralDisable(SYSCTL_PERIPH_WDOG1).

Best Regards
Santosh Athuru

Hi Santosh,

I tried to use these methods already before but it seems not to change anything, do you have any other suggestion what it could be?

I also have the problem that sometimes the C28 core runs in some memory area where no code resides. So I click Reset CPU, then click restart, after that it runs to main() (like after a program load) then I click on run. If I pause the program then sometimes it is on a normal program code (works correctly) but sometimes it is at some written adress 0x10ad.... I did not check if it is always the same adress...

then I have to redo the resetting and restarting of the program and it works correctly. what could that be and how can I check if the program works correctly without pausing the program all the time.

kind regards
Andreas

Andreas Unterberger said:

I tried to use these methods already before but it seems not to change anything, do you have any other suggestion what it could be?

Andreas,

on M3, since you are able to step through the code before it hits hard fault, can you check from the dis-assmebly window on what happens after the writes to flash when program returns to the point where it fails?

I'm sure the above API disables the watchDOG, but if isn't solving your problem then watchdog might not be the one causing the problem. we need to look further, please do assembly single step (before it hits HARD FAULT) and see if any bad instruction is being fetched from the dis-assembly window. 

Andreas Unterberger said:

I also have the problem that sometimes the C28 core runs in some memory area where no code resides. So I click Reset CPU, then click restart, after that it runs to main() (like after a program load) then I click on run. If I pause the program then sometimes it is on a normal program code (works correctly) but sometimes it is at some written adress 0x10ad.... I did not check if it is always the same adress...

The above might be a different issue, try to increase stack size. could you just run C28x is a while(1) loop till you fix the above problem with M3?

Best Regards

Santosh Athuru

 

Hi Santosh,

in the mean time I found out that the hardfault is only generated if the program (flash memory) is overwritten with some values. So basically I tested my flash driver to be able to write to any memory adress in flash.
For the first step I do not need that the application is able to update itself, so I moved on to write to a memory which is not allocated by the current application.
So I did not do the disassembly stepping until now but I'm sure it has to do with the writen testdata in the flash. However at the moment this is acceptable, but if you have any ideas what exactyl is causing this I would appreciate it! I'm sure that all parts of the program executed are loaded to RAM while flashing the memory.
So it may be a different interrupt routine which I do not know is executed in background maybe and so I also did not move it to RAM or so...

regards
Andreas

Andreas,

you are programming with ECC enabled correct? Try by disabling ECC and if the error doesn't happen then this could be because of ECC.

I'll ask our flash programming expert to look at this.

Best Regards
Santosh Athuru

Andreas,

When you program Flash using API, you can program ECC using AutoEccGeneration mode. When using this mode, you need to provide either 64-bits of data or 128-bits of data (aligned on these boundaries) since ECC gets programmed for every 64-bits aligned on a 64-bit memory.

If you want to program less than 64-bits and want to program the remaining of the 64-bits later, you can program using DataOnly mode initially and later program all the 64-bits again with AutoEccGeneration mode. However, if you plan to read/fetch the partially programmed 64-bit data (before ECC gets programmed), make sure to disable ECC before you read/fetch that data to avoid ECC errors (Flash0EccRegs.ECC_ENABLE.bit.ENABLE = 0x0;).

You can program less than 64-bits using AutoEccGeneration mode only if you are OK to lose the space that you did not program with in a 64-bit aligned memory. AutoEccGeneration mode assumes all 1s for the data that is not provided in a 64-bit aligned memory. Once you program a 64-bit aligned memory with AutoECC, you will not be able to program the rest of the bits in that 64-bit aligned memory (unless you erase) since ECC is already programmed.

Thanks and regards,
Vamsi

Andreas,

Any update on your debug?  Did you program ECC correctly?

Thanks and regards,
Vamsi

Andreas,

I am closing this thread for now.  You can reopen it if you have any questions.

Thanks and regards,

Vamsi