• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 98 subscribers
  • Views 401 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.

Quick DMA shutdown

Leon de Wit
Intellectual 470 points

Hi everyone

I'm looking for a way to quickly shut down all DMA on my DM6437. I'm aware of the 'proper' way to shut down the channels in use, but for speed reasons these aren't working all that well for my application.

I don't care about recovery after the shutdown, since my aim is to load another application as soon as possible. The new application will do all setup from scratch as required.

I thought about just powering down the DMA controller, but I feel there has to be a better way. Also, I'm not sure that approach would be safe.

To shut down DSP/BIOS, I simply disable all HW interrupts. I was hoping there might be something similar I could do for DMA?

I've searched the registry descriptions in spru987a.pdf, but I've not come up with exactly what I am looking for. I'm hoping someone has some ideas?

Thanks

Leon

 

 

  • 0
    TI__Guru*** 125430 points

    I recommend clearing the EER.  You could additionally write CCNT=0 to all the active parameter sets.  That way you won't have to wait for the transfers to run to completion since they'll simply be dummy transfers that do a 0-byte transfer (with no errors introduced).  There's no way to abort a transfer that's already begun in the Transfer Controller.

  • 0 in reply to Brad Griffis
    Intellectual 470 points

    Hi Brad

    Thanks for the reply.

    I did as you suggested, and cleared both EER registers for my device and wrote 0 to the CCNT fields in all parameter sets. I still find that something is writing to my DDR memory, specifically to the memory declared as

    86134c80    00052b00     os_sem.lib : pbm.o64P (.far:NDK_PACKETMEM)

    in my map file. What I don't understand is, if we've disabled all HW interrupts and all DMA access, how are these ethernet packets ending up in my memory?

    Thanks

    Leon

  • 0 in reply to Leon de Wit
    TI__Guru*** 125430 points

    The Ethernet MAC does not utilize the EDMA. It can directly master writes to memory and has its own descriptor memory (CPPI). 

  • 0 in reply to Brad Griffis
    Intellectual 470 points

    Hi Brad

    Thanks, for the answer. I've been reading through the EMAC documentation to get a better grip on what is happening there at the HW level.

    Basically then, to have complete control over a block of memory, I need to ensure no other threads are accessing it (done), I need to ensure it's not being accessed via DMA (done) and I need to make sure other SOC devices can access the memory (next on my list to look into)

    Is the above list complete? In other words, will this ensure that a specific thread is the only actor accessing the memory in question?

    Secondly, how would you suggest I deal with all the devices that may be able to directly do master writes to memory? From an architectural point of view, I'd ideally like to implement this on a high level, so the top module doing this memory switch and load does not need to know implementation details of the lower down modules supporting it. Disabling HW interrupts is a good example of a very clean way of stopping everything happening on the DSP itself, with the option of continuing seemlessly later on if required. Is there a way to do something similar on a SOC level?

    Lastly, where can I read up on memory management on the 6437? I'd like to understand better how the different memory master writes interact. I also need to know which devices can possibly issue master writes, in case it proves necessary to disable them one by one.

    Many thanks

    Leon

  • 0 in reply to Leon de Wit
    TI__Guru*** 125430 points

    Leon de Wit said:
    Lastly, where can I read up on memory management on the 6437? I'd like to understand better how the different memory master writes interact. I also need to know which devices can possibly issue master writes, in case it proves necessary to disable them one by one.

    See Table 4-1 "System Connection Matrix" from the data sheet.  The column on the left lists all bus masters capable of writing directly to memory.

     

    Leon de Wit said:
    Secondly, how would you suggest I deal with all the devices that may be able to directly do master writes to memory? From an architectural point of view, I'd ideally like to implement this on a high level, so the top module doing this memory switch and load does not need to know implementation details of the lower down modules supporting it. Disabling HW interrupts is a good example of a very clean way of stopping everything happening on the DSP itself, with the option of continuing seemlessly later on if required. Is there a way to do something similar on a SOC level?

    You'll need to take it on a case by case basis for each bus master.

    Perhaps a different way of doing this would be to force a reset of the device (e.g. through an invalid key to the watchdog) and then have your bootloader code decide which application it's going to load.  I think you could put a magic word (e.g. 0xdeadbeef) followed by an application code (e.g. 1,2,...,n for your n different applications).  Before you trigger the reset your application would just make sure that the magic word and the next application code are in there place in memory.  This approach would stop everything immediately and put the entire chip into a known good state, except for the internal SRAM which is unaffected by a reset aside from the pieces that are used by the boot ROM.  You would have to spend some time reconfiguring the PLLs and DDR2, but you would save a lot of time elsewhere trying to put peripherals in a known state.

  • 0 in reply to Brad Griffis
    Intellectual 470 points

    Hi Brad

    A complete system restart is probably the way to go. Thanks for all the advice!

    Leon

     

    PS: Would you believed I searched everywhere for that memory information, but never thought to look in the datasheet itself. Oops!