• State
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 376 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Secondary bootloader and MCASP,DMA problems

Chris Hofer
Prodigy 90 points
Other Parts Discussed in Thread: TMS320C6745

I am using the TMS320C6745, connected to an FPGA that is providing 20 MHz main clock and 10 MHz clocks to the MCASP0.

I have created a secondary bootloader that boots from external serial flash via the ROM boot.

1. My secondary boot loader waits for 10 second for any serial comms (used to load new application)

2. then proceeds to load my application from external serial flash (starting at page 1) into L2 RAM.

3. Completes loading the application by reading the jump and close command and branching to applications c_int00 address.

My application is using the MCASP to drive 2 DACs on MCASP1 and read 10 ADC from MCASP0, both using EDMA.

The problem is that, when the secondary bootloader loads my application, the MCASP0 fails to generate receive events for the DMA.

I know that my application code works correctly because I can run it in the debugger and everything works as intended. It seems to be related to the difference between a POR initialization of the MCASP vs a branch to c_int00.

I know that my secondary bootloader is coping the code correctly, because I have done a memory compare between the image that the secondary bootloader loaded, and the image the debugger loaded.

Does anyone have any thoughts or ideas especially relating to the initialization of the part after the secondary bootloader is finished?

  • 0
    TI__Guru* 84110 points

    Chris,

    Usually, when an application works under emulation and not when booted from the Flash, there is some initialization that is done automatically by GEL files that needs to be done from the Flash. The GEL functions that start with On...(), such as OnTargetConnect() or OnFileLoaded() or OnReset(), will be executed by CCS to help you with running your application. Some of the configuration that is done there must also be done in your Flash, but that is not always obvious.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 90 points

    Randy,

    My application work correctly when booted from flash using the ROM boot (No secondary bootloader). I am assuming that the ROM boot does some of the same initilization step that the GEL file do when under emulation. Can you confirm this?

    Chris

  • 0 in reply to Chris Hofer
    Prodigy 90 points

    Randy

    What is the file name for the GEL file used for the TMS320C6745 in CC version 5.2.1.00018?

    Chris

  • 0 in reply to Chris Hofer
    TI__Guru* 84110 points

    Chris,

    When you open a Target Configuration and select the Advanced tab, the script file will be shown on the right side of the pane when you select the C674x core on the left side of the pane.

    I do not have this installed, so I do not have the exact name. You can also find the file name from the GEL Files window if you enable that from one of the menu items.

    Regards,
    RandyP

  • 0 in reply to RandyP
    Prodigy 90 points

    Randy

    I don't believe that my target configuration is using any GEL file, at least nothing is listed in the "initialization script box" on the right when I select the "C674X_0" core on the left. I typically manually initialize all my peripherals when my code begins.

    I really think the problem is that the McASP0 doesn't "pass" the recieve event to the DMA. I have setup DMA param 0 with a CCNT = 40. When the problem occurs, I stop the code with the emulator and inspect CCNT on param 0 and it has decremented to 39. It appears like there rest of the receive events have been lost, but the EMR register is all 0s.

    Do you have any suggestions as to why the MCASP0 would stop generating receive events. The code does bursts of samples every 100ms, the MCASP0 is reset before every burst and I cannot seem to get the MCASP0 port to recover. Keep in mind this problem only occurs when the application is loaded via my secondary bootloader.

    Chris

     

  • 0 in reply to Chris Hofer
    TI__Guru* 84110 points

    Chris,

    The only reason for the McASP0 to not pass a receive event is that it has passed one that was not serviced. Each event must be serviced before another event will be presented to the DMA.

    Regards,
    RandyP