F28235 boot loader issue

Anna,

There is an errata for the XINTF on this device that may be causing the issue.  It is described in www.ti.com/lit/SPRZ272

Memory: Possible Incorrect Operation of XINTF Module After Power Up

Regards,

Lori

Lori,

Thank you for your reply!

I am not sure if this is the reason. Because when we use the small application that without using DSP BIOS to do the jump, it always works.

Can you think of any other possible reason?

Thanks,

Anna

Anna,

so it looks like a DSP/BIOS related problem. Can you check, if the external memory interface was initialized correct within DSP/BIOS? I would recommend to do a test within your BIOS application:  Try to read some locations from external flash in a BIOS-task and verify if the data are correct.

Another idea: From where do you branch into the external flash, is it a task  or a software interrupt? What is the status of the stack when you do the branch?

FRank

Frank,

Thank you very much for reply. Yes, I also think it might be DSP/BIOS related, but don't know why.

I think the external memory interface was initialize correctly. 

Because  that

a.  In the BIOS application, I tested read some locations from the external falsh in a SWI ISR ( we didn't use tasks, we only use SWIs), the data are correct.

b. We had put some data in the external flash, e.g. big string arrays. in the BIOS main application we use these strings without any problems.

c. When I did the jump to the external flash to run the boot loader, with the CCS4 emulator Disassembly Window, I can see it did jump into the external flash entry point (0x00298064) and also I can do the assembly step into.  Unfortunately there is no source code provided for the external flash application in the Disassembly window, I can't tell where/what was executed.  

I did the branch into the external flash from a software interrupt. Could you please tell me how can I tell the status of the stack?

I  suspected maybe the PRDs or SWIs cause the reboot/reset, so before I did the branch, I have stopped all the PRDs and use SWI_disable(); to disable all the software interrupts.    I even disabled the watchdog.  By calling the following function:

But all of these didn't help.

Do you have any other idea?

Many thanks,

Anna

void InitWatchdog(void)

{

      asm(" EALLOW");                                 // Enable EALLOW protected register access

      SysCtrlRegs.WDCR = 0x00E8;

// bit 15-8      0's:    reserved

// bit 7         1:      WDFLAG, write 1 to clear

// bit 6         1:      WDDIS, 1=disable WD

// bit 5-3       101:    WDCHK, WD check bits, always write as 101b

// bit 2-0       000:    WDPS, WD prescale bits, 000: WDCLK=OSCCLK/512/1

      SysCtrlRegs.SCSR = 0x0000;

// bit 15-3      0's:    reserved

// bit 2         0:      WDINTS, WD interrupt status bit (read-only)

// bit 1         0:      WDENINT, 0=WD causes reset, 1=WD causes WDINT

// bit 0         0:      WDOVERRIDE, write 1 to disable disabling of the WD (clear-only)

      asm(" EDIS");                                   // Disable EALLOW protected register access

} // end of InitWatchdog()

Stack: Set a breakpoint at your LB - line and check how far the SP has gone in your stack section and how many spaces are left. If your new program in external memory initializes a new C environment (_c_int00), then it would help to reset SP to its start value, as user "quark" recommended in your other thread.

Source Code in external memory:  Why don't you see the source code? If the code is part of your project, you should be able to open the corresponding file(s). If you are not sure, which file is active, the just right click in the disassembly and activate "show source" - this should help you to locate the correct source. Then I'd recommend that you try to single step the external code and see how far you can go before it crashes.