TMS320F28388D: TMS320F28388D

Hi Dorion, 

Is it correct to assume that you are using Flash boot mode?  Now to play back what you have described is the following correct?

1. The ROM boot loader recognizes flash boot mode.

2. You have confirmed that the ROM boot loader calls the secondary boot loader successfully.

3. The secondary bootloader checks for a valid image at location (0x208000) and it is able to detect it correctly.

     a. One question here, what happens if there is no valid image at this location 0x208000?  what happens?

4. Beginning execution at 0x208000 results in the exception.

Can you confirm that steps 1, 2 and 3 all work successfully.  if not, do you know which one is the first point of failure.  Also, please answer 3a as well. 

Thanks, 

Krishna

Krishna

So 1, 2 and 3 yes they do work and correctly. The secondary boot loader is at addr 0x200000 which is the start of the CM flash.

To answer you 3a, we will then flash new code to sector 0x208000 by getting it from CPU1 over the IPC messages.

Yes step 4 throws the fault Exception looks like Interrupt Vector 1. My run-able flash code starts at 0x208000. 

Ok thanks.  So for step 4, have you tried running the application under the control of the debugger, with a valid application, where you set the PC to the desired address.  If you do that, are you able to step, run and halt the application successfully?

Regards,

Krishna

Krishna,

  Yes for step 4 I have been able to load the runtime application into the debugger and it works.

  I think you are asking if from the boot load if I change the PC to the runtime address does it work? I have not, what is the best way to do that in C code.

Dorion

 

Krishna,

  If I flash the runtime code into the 0x208000 flash sector and then run the boot loader from the debugger and change the PC to 0x208000 it seems to start to run the runtime code.

  So it looks like your suggestion should work. Now I need to somehow do this in my main application in the boot loader. So what is the asm instruction to change the PC?

Dorion

Hi Dorion, 

Have you been able close on the issue you were trying to resolve.  If you perform the operation as follows, for example:

uint32_t  runFromAddress; 

runFromAddress = 0x208000; 

    ((void (*)(void))runFromAddress )();

You can see several examples of this use case in our bootROM software available in C2000Ware.  Depending on your installation you can consult the source available here: <...>\C2000Ware_4_01_00_00\libraries\boot_rom\f2838x\revA\rom_sources\cpu1\F2838x_ROM\bootROM

Regards,

Krishna

I will try this again on Monday although this is what I stared with when I was getting a CPU error.

If I am in the debugger and manually change the PC it seems to work with no CPU error interrupt.

I was waiting on an example of assembly code to change the PC.

You can view the disassembly in the debugger.  When this instruction  ((void (*)(void))runFromAddress )(); runs in the debugger, you can single step in assembly and observe the relevant registers in the register window and monitor the program flow.

Regards,

Krishna

Krishna,

I did what you suggest above. The assembly does the following:

mov.w r0, #0x208000
blx r0

This actually does jump to the runtime flash code which resides at 0x208000 but the problem is I now throw an exception and end up in the default fault handler.

if, when I am in the debugger, just change the PC to 0x208000 then I do not end up in the default fault handler function.

So what am I missing?

When you are running this under debugger control, you can set the PC to 0x208000.  From that point on, are you able to single step, run etc., normally?

Thanks, Krishna

Yes. with no errors and no ISR interrupts.

That is what is weird.

Thanks...just trying to understand, at what point the target hits the exception.  So in your assembly code above, the mov.w work correctly and r0 gets the right value.  Then the blx r0 executes and you see that the PC get loaded with the expected address (0x208000).  Is this correct? Now when you single step from the new PC location, the target gets confused.  Can you please elaborate on the point of the failure? 

Also is it possible for you to do a global disable of all interrupts right before you execute the 2 instructions (mov and blx) stated above.  What happens then?

Thanks,

Krishna

Krishna,

  Ask away...

  When in the debugger I use the assembly window to step when I am about to hit the blx,  The mov.w command loads r0, the next step then goes to 0x208000 and the PC is at that address.

  This is the runtime code and the first thing that does is a b.w #0x228466 which should be a function called (resetISR) which in turn is supposed to jump to _c_init00, when I do the next step from the resetISR we end up in the faultISR  Registers are and it indicates faultISR 1.

  The resetISR is the address at the beginning of flash and gets called when we get a reset from the board, this again just jumps to the main application.We never get father than the initial call into the resetISR.

  What is the best way to disable all global interrupts?

  If I just set the PC before the blx call everything seems to work correctly.

Dorion

Krishna,

  here is what I am doing same results. Just to the Fault ISR.

int main(void)
{
//    Fapi_StatusType  oReturnCheck;

    //
    // Initialize device clock and peripherals
    // Copy the Flash initialization code from Flash to RAM
    // Copy the Flash API from Flash to RAM
    // Configure Flash wait-states, fall back power mode, performance features
    // and ECC
    //
//    CM_init();

//    __asm("    b     #0x00208000");
    Interrupt_disableInProcessor();
    ((void (*)(void))APP_START_ADDR )();

}

So here with the debugger, you can stop at this line:  

((void (*)(void))APP_START_ADDR )();

and then you are able to single step and everything works fine.  Is that the correct understanding?

Thanks,

Krishna 

I did stop at the line, I single stepped and it still calls the ISR Fault but this time in the runtime application.

Which is weird if ISR are disabled right?

I am not sure exactly what Interrupt_disableInProcessor(); does. Please use DINT for disabling interrupts instead.  Then, when the execution stops at this line:

((void (*)(void))APP_START_ADDR )();

Use "Assembly Step", at this point and please spell out what you see after each assembly step.

I cannot find a DINT for CM. So I am doing this:

    _disable_interrupts();
    ((void (*)(void))APP_START_ADDR )();

Here is the output from the debugger after trying to step with assembly.

Cortex_M4_0: Can't Run the Indicated Number of Instructions on the Target CPU: (Error -1268 @ 0x1090009) Device is locked up in Hard Fault or in NMI. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.2.0.00002)

Krishna,

  Maybe I am asking the wrong question. Let me explain what I am trying to do maybe there is a better way of doing it.
1. I have a bootloader CCS project and I have the flash_lnk file setup so it resides on the CM at Addr x0200000, this program gets launched when power is applied to the system.

2. I have another CCS project call runtime app, I have the flash lnk file setup so it resides on the CM at 0x208000

3. Using the debugger I flash the runtime app.

4. Using the debugger I flash and run the bootloader project, all I want it to do is jump to 0x208000 address and run the RuntimeApp. As a simple example.

5. Whenever I run with or without the debugger I get a FAULT interrupt and end up in the default FAULT handler. Which appears to be some HARD fault.

6. If I disable CM interrupts, I still get the FAULT but we don't go to the fault interrupt handler the debug probe dies.

So my questions should be how do I configure the runtime app such that it can be called from the bootloader?

Dorion

Krishna,

  Following up on my last comment.

  I have been still playing around with things and this appears to allow me to get to the runtime code but something still isn't right, the runtime code is not working correctly. It is almost like interrupts or some initialization is not correct. IPC doesn't seem to be working.

Remember this is on the CM processor.


int main(void)
{
    __asm("    mov R0, #0x00208000");
    __asm("    mov PC, R0");
} 

Krishna,

  Any feedback on my new posts?

Hi Dorion, 

Apologies for the delay...we will have to find the right domain on this and get back to you shortly. Regards, Krishna