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.

GEL command: GEL_AdvanceReset

Hi,

I am running a custum board with TMSC6747 DSP. I had a problem of McASP hanging issue while loading the DSP code through the HPI bootloader. However, when I run the code through the JTAG port, the problem went away. So it looks like that the GEL script does something I don't do in the HPI bootloader. I narrowed down the command: GEL_AdvanceReset ("System Reset"). I wonder what is done in this GEL command regarding initializing McASP.

Thanks,

Ru

 

 

  • So if you remove that command and power cycle the board, your code will fail even through JTAG? What if you move that command to the very start of your GEL file? If it is later in the code, it could be erasing the settings performed before it.

    Jeff

  • If I remove that command, my code will fail even through JTAG. I have removed all other commands in the GEL file. This is the only command in my GEL file. I also tried "GEL_Reset()" command, which did not solve my problem.

    Thanks, Ru

  • Jeff,

    We are trying to determine a cause for an issue in our DSP where the SIO_reclaim API stops functioning correctly.  Through testing, we notice the problem doesn't seem to happen if we use a JTAG debugger and connect to our target and execute.  The problem happens fairly consistently when we let the target boot-up on its own - which is HPI boot.

    Ru has done testing with the GEL file associated with the C6747 and has observed that when the GEL function call GEL_AdvanceReset ("System Reset") is called on Target Connect, the issue doesn't happen.  If this function call is commented out in the GEL script, then even using our JTAG we do see the problem with the SIO_reclaim - (that issue being the function call creates a blocking condition on the task that is never unblocked).

    We are speculating that when the HPI boot load program is running within the DSP, some register is changed from its reset value that is contributing to this problem.  We need to know what registers this GEL function touches so we can essentially duplicate this action after HPI boot loading has completed.  We are hoping this will fix the issue or at least point us to some register that indicates the problem.  Right now, when this indefinite blocking condition occurs, all the McASP and EDMA registers we examine do not indicate any errors.

    So the most helpful thing would be if you could tell us what the GEL function GEL_AdvanceReset ("System Reset") does in the C6747 so we can translate this to C code and add it (or portions of it) to our initialization function.

    thanks,

    Mike

  • Lets move this post to the CCS forum and start another thread once that has been determined.

    Jeff

  • As far as I know, A system reset will reset the CPU and on-chip peripherals. It varies from chip to chip. I'll try to get more details on what exactly happens on a C6747.

    ki

  • Thanks Ki.  This is still a high-priority issue for us and we'd like the details for the C6747.  That particular GEL command must break down into a series of writes to on-chip registers that resets the various peripherals.  If we could get that psuedo code, it would help a lot.

    And here is a related question that might help us as well.   Our target has the C6747 boot config pins set for HPI boot out of power-on reset.  What on-chip peripherals does this ROM program use?  My guess is that this program is enabling some peripheral that needs to be reset again to prevent our issue from happening.  I say this because, if we connect to the target via JTAG and issue the GEL system reset command, we can load and execute our program  without issue.

    Mike