problem with tms570lc4357 uart bootloader

Hi Jinus,
Can you please find out the cause of the data abort by looking the DFSR (data fault status register) and DFAR (Data fault address register) inside the CPU CP15 registers? I'm guessing the abort is either due to MPU violation or privilege access violation. The RTOS will operate the CPU in user mode. However, some of the system resources can only be access written in privilege mode. It is possible that the abort is due to an illegal access violation when the CPU while in user mode is writing a register which is protected in privilege mode.

Some function of the F021 flash API must operate in a privileged mode. Use "xTaskCreateRestricted()" to create a task that operates in system mode.

Hi Charles and Bob,

Thanks for your reply!

CPU15 register value :

Actually CPU will goes to data abort after execute LDMFD   SP!, {R0-R12, LR, PC}^ 

How to fix that problem?

I have a question.

When the bootloader startup, CPU MEM ESM etc were configed at this time. But those configuration should only be  valid in "bootloader time", when user app starts, CPU MEM etc should be re-initialized in user-configure mode. I think the booting process should be so.

Therefore user app with RTOS should runs fine when called  by bootloader, But actually not. Why bootloader configuration has effects on user app configuration? 

Thanks!

Jinus

Best Regards!

Hi Jinus,

 The status register indicates that the abort is due to a write operation. Since the error is imprecise, the error address is unpredictable. The value in the data fault address register which currently shows 0x00000000 is unreliable. As indicated by Bob, the error could be due to writing to a privileged protected register while the CPU is operating in user mode. Please try to create xTaskCreateRestricted() task and see if that makes a difference. 

Can you show the reading of the RAMERRSTATUS register in the L2RAMW module? Any flags are set?

Hi Charles,

Thanks for your help.

L2RAMW registers value:

I did not make my question clear. The app project was downloaded from MICRIUM  and it works if not called by bootloader(vector table begin with 0x00000000). So i think the problem can not occur in app. I make some chages in bootloader and it works. The first uncheck "Enable IRQ Handing via VIC controller", The second, comment out "_copyAPI2RAM_();" and make flash api run from FLASH Bank0 while user app will flash into BAKN1.

I am wondering why bootloader configuration had effects on user app. How to make changes on user app startup code that can make CPU MPU etc runing as app wished and not affected by bootloader? How to init cpu mpu etc in user app?

Thanks very much!

Best Regards

Jinus

Hi Jinus,
Glad that you are making good progress. I think by default, the bootloader assumes the custom application will use "IRQ Handling via VIC Controller". Micrium OS3 does not use this mode. The RTOS has to have full control on how to manage IRQ. So what you changed makes sense and that I think is reason why it works now. The part that I didn't understand is why removing _copyAPI2RAM_() will make a difference. In the bootloader example, it copies the F021 API to RAM and executes the API in RAM. This is to allow program/erase on the bank0. The reason is that you cannot program/erase on bank0 while you are executing code out of bank0. I understand that you will flash your application code to bank1 and you no longer need to run the API from RAM. But I think it should work to still have the API run from RAM. Have you tried that in addition to disable the VIC port?

Hi Charles,
Sorry for my late reply. These days i have been busy on other projects.

Have you tried that in addition to disable the VIC port? Yes !

I think, Copying fapi functions to ram will make memorys worked in Privilege Mode, is that true?

Best Regards
Jinus