McASP and power down problem

Hi Blair

Have you kept in mind the constraints listed when using Power_sleepDSP in the following wiki

You need to make sure PLL1 bypass etc , if being automatically done, is not impacting your system functioning?

Regards

Mukul

Yep, took that into account. I'm using standby with the following call

Power_sleepDSP(Power_STANDBY , 0, 0);

If I disable the McASP sampling task everything works as intended, but if I allow the McASP to run then the system hangs. I'm using the McASP driver that ships with PSP and the EDMA3 driver as well. I've configured things to use standby so the PLL's are left untouched. I'll check if the McASP driver even returns one buffer before things hang, but if memory serves me correctly the McASP doesn't generate a single clock and things hang on the first call to Power_sleepDSP. If I simply idle the processor, no other changes other than replacing the PowerSleepDSP call with

Hwi_disable();

REG(PDCCMD_REGADDR) = 0x5555;

_PMI_doIdle();

Then everything works well. The diference is that this does not set the MEGPD bit. If I simply change the setting to 0x15555 then the code hangs.

Blair

 

 

Hi Blair
Without writing to MEGPD bit you are not really doing anything to the state machine of the c674x module. Writing to this bit and then executing idle instruction, maximally cuts clocks internal to DSP SS.

Details in SPRUFK5A (snapshot below). To come out of this mode, you will need an interrupt setup to wake up etc.

Additionally , please evaluate the OMAPL138 power consumption summary and power estimation application note, to understand the difference between just IDLE and PDCMD IDLE (MEGPD set) , from a power saving perspective, to ensure that for a given frequency and voltage of operations, the relative power savings you get is worth the software complexity , for your end application.

Regards
Mukul





----
C674x Megamodule Power-Down
NOTE: Powering-down the C674x megamodule as described in this section is often called static
power-down. This term is used to describe this power-down mode since this mode is often
used for longer periods of time. The term dynamic power-down used in this chapter implies
that the power-down mode is used for limited periods of time.
The entire C674x megamodule can be powered-down using the following procedure. Other than the
options previously specified, it is not possible to power-down only part of the C674x megamodule.
Powering-down the C674x megamodule is completely under software control by programming the
megamodule power-down (MEGPD) bit in the power-down controller command register (PDCCMD).
The following software sequence is required to power-down the C674x megamodule:
1. Enable power-down by setting the MEGPD field to 1 in the PDCCMD register.
2. Enable the CPU interrupt(s) that you want to wake-up the C674x megamodule. Disable all other
interrupts.
3. Execute the IDLE instruction.
The C674x megamodule stays in a power-down state until awakened by the interrupt(s) that are enabled
in step 2.
If a DMA access occurs to the L1D, L1P, or L2 memory while the C674x megamodule is powered-down,
the PDC wakes all three memory controllers. When the DMA access has been serviced, the PDC will
again power-down the memory controllers

Thanks Mukul. All the required interrupts are set and active as they are required to get out of idle as well, I think. Everything works when using idle so the interrupts seem to be working and I've check the appropriate registers to verify what interrupts are enabled. I did a quick test with the McASP disabled and the power savings seem to be significant in our application so there is great interest in getting it to work with the MEGPD bit set. I'll take a look at the app note to verify.

I'm assuming that there is no fundamental reason that we should not be able to set the MEGPD bit while using the McASP with EDMA?

Blair

Ok, good to know, yes you are right you need the interrupt for IDLE too.
I will ping the folks on TI RTOS forum. ScottG is knowledgeable about the PWRM product.

No i don't know of any limitations that prevent you from using MEGPD with McASP+EDMA. However given that bit does internally clock off several internal modules within DSP SS , it may be causing some sort of race condition/ timing issue between stuff getting woken back up vs when McASP/EDMA is servicing.

Do you have dependencies on internal DSP SS memory for your program/data? Payload for McASP in L1/L2 or Shared RAM ? Any other things going on besides McASP+EDMA , that maybe depedent on DSP SS idle but not getting "notified" etc? We may need to further understand what hang means? State of processor, state of EDMA and MCASP (looking at register dump of these modules)

Regards
Mukul

Mukul:

Thanks for the quick response. I'll look into getting a register dump and attach it to a post later today. The EDMA is filling a buffer in L2 and I've assumed that this would be alright from the comment in section 9.2.5 of SPRUFK5a where it says "If a DMA access occurs to the L1D, L1P, or L2 memory while the C674x megamodule is powered-down, the PDC wakes all three memory controllers. When the DMA access has been serviced, the PDC will again power-down the memory controllers." I read this as the L2 memory will power up the EDMA write will complete and the clock will then be shut off to L2. Did I understand this correctly? As for dependendencies on the DSP SS I'll have to ask you what the SS stands for? If it is sleep system then there shouldn't be any, but the information is spread across several documents so it is entirely possible that I've missed something.

Thanks again,
Blair

Yes, as per the documentation , the memories should be accessible on when there is a request - is that what you are assuming and operating at or are you actually going through the process of waking up the DSP via interrupt and then access the memories for whatever McASP and EDMA interaction is needed with the DSP? Usually I have not seen customers rely on the auto service/wake feature etc though.

By DSP SS I meant DSP SubSystem , all i really meant was the c674x megamodule that includes DSP core, caches, memory systems local to DSP (excludes shared ram and ddr etc) and other components within the megamodule.

Yes, the information is still a bit scattered, even though we try to cover the most relevant ones in the TRM between the PSC and power management chapter.

Another debug suggestion would be to see if a simpler memory to memory transfer to/from L2 works with this setup - to see if the issue is more with McASP or EDMA.

Thanks. I'll give the simple memory transfer a try and see what happens. You are correct that we were planning on using the auto service/wakeup feature. That way we don't have to worry about the EDMA3 driver details or so we hoped. Once I gather some more info I'll post the details, probably tomorrow.

Blair

It looks like it is McASP specific. Other memory transfers work just fine using EDMA. I notices that there are 32 frames transfered out of 1024 required then the system stops any McASP transfers for a bit then does another 32 and the process repeats. Any chance that the clock fail check is causing issues when I set the MEGPD bit in the power down register?

Blair

Some more details. It seems that I now have the system working after a fashion. The system samples at 512000 samples per second and what I want to do is sleep for most of the 2 msec required for it to collect 1024 samples with the McASP and EDMA doing most of the work. Once EDMA transfers a 1024 sample buffer the system wakes up and processes it. During the sleep interval I want to slow the clock down and sleep the core using the MEGPD bit in the PD register. I've arranged the clocks so the McASP is clocked externally. All bit clocks and frame sync are provided by the McASP to the ADC.

When I reduce the clocks as much as I'd like the McASP frame synch seems to show 31 samples then a gap followed by another 31 samples in a pattern that repeats. This does not happen when I simply idle the core, only when I set the MEGPD bit. If I do not reduce the clock while sleeping then all is well and setting the MEGPD bit works correctly. Is there some minimum relationship between the two clock sources used in the McASP? Inparticular the bit clock and the ASYNC3 clock.

Thanks,

Blair

Blair
Thanks for the updates. Looks like some progress and hopefully you are getting closer to your end goal

From your previous post
>> Any chance that the clock fail check is causing issues when I set the MEGPD bit in the power down register?
[MB] There is no direct relation betweeen McASP clock failing/working with MEGPD bit set/ not set

When I reduce the clocks as much as I'd like the McASP frame synch seems to show 31 samples then a gap followed by another 31 samples in a pattern that repeats. This does not happen when I simply idle the core, only when I set the MEGPD bit. If I do not reduce the clock while sleeping then all is well and setting the MEGPD bit works correctly. Is there some minimum relationship between the two clock sources used in the McASP? Inparticular the bit clock and the ASYNC3 clock.

[MB] Ok , will probably need some details on how much you are slowing down the device clock. Slowing device clock has direct impact on EDMA clock, McASP state machine that is sourced by PLL0_SYSCLK2 or PLL1_SYSCLK2 etc. There is likely an overhead to access memories when MEGPD is set and it goes through auto wake etc , that is likley causing an issue, is my guess.

I am not aware of any minimum relation ship , but it will be good to document what are the actual clock speeds you are working with.

So additional debug suggesitons
1) Is the source/destination for McASP in DSP L2? If so , can you try Shared RAM instead - to further see what is the direct impact on McASP working on MEGPD.
2) See if there is a sweet spot for slowing down clocks, where potentially you do not see an issue with MEGPD.
3) More complex, but if you are truly trying to scale frequency , the ASYNC3 mux for PLL0_SYSCLK2 vs PLL1_SYSCLK2 was done for this reason - to keep some key serial peripherals immune of main clock frequency change. You can try PLL1_SYSCLK2 as source for McASP. DO keep in mind that it will also then be the source for ECAPs, UART1/2, Timer64P2/3, eHRPWMs, McBSPs, McASP0, SPI1 too.
4) Need to further understand what is meant by not working? Are you seeing EDMA error registers set or you seeing any McASP overflow/underflow registers. Perhaps that will give more clues no what is not working.


You may already be aware but the following PLL clocking spreadsheet is handy tool for understanding various clock relationships etc

processors.wiki.ti.com/.../AM18xx

Regards
Mukul

Mukul:

Thanks for the fast response. The clock is set to run at 216 MHz when processing and cut in half to 108 MHz when sleeping and waiting for the buffer to fill. Once the system starts the whole thing is run off PLL1 and PLL0 is places in bypass with the bypass clock coming from PLL1 SYSCLK3. The McASP is left with a constant clock driven from PLL1 SYSCLK2 with CFGCHIP3[ASYNC3_CLKSRC] set to one. The system clock is reduced from 216 to 108 MHz by changing the SYSCLK3 divider in PLL1. Since PLL1 SYSCLK1 and PLL1 SYSCLK2 dividers are left unchanged then the internal McASP clock should remain constant. The bit clock for the McASP is driven from a separate external clock at 20.48 MHz. You are correct that this arrangement cuts the EDMA clock in half from 216 MHz to 106 MHz so I'm wondering if that might be the issue? Any idea how many EDMA clock cycles are required to move a word from the McASP to L2 RAM?

I'm running this on the LDCK at the moment and have the McASP set to use the transmit clock for the receiver. This is done because the McASP clocks are not routed out to a connector and I'm pumping the transmitter with garbage data to get the clocks to drive my ADC (another TI part the ADS8881). This means that, at least for now, my main sampling task is set up to drive the transmitter and read the receiver. This would cause double the EDMA activity so that may be an issue as well.

Blair

It has been a while since I saw anyone use the full frequency scaling and PLL1 bypass options etc :). Impressive.

Unfortunately I don't think we have a single word access latency for EDMA-MCASP to L2, but please see if the following data (actually a lot of data) helps to correlate with your McASP clock settings/ throughput rate etc?
processors.wiki.ti.com/.../AM1x_Multichannel_Audio_Serial_Port_(McASP)_Throughput_and_Optimization_Techniques

Alternatively if we assume that the 108 MHz configuration and associated EDMA slow down is the primary reason for things not working, due to potential overhead of the handshake to L2 with MEGPD set, perhaps you can see if you can see things start failing at a lower but close to 108 MHz frequency , w/o MEGPD?

If you still see things working robustly at a lower frequency , perhaps the issue is somewhere else.
Regards
Mukul

Hi Blair
Thanks for the update. I appreciate you capturing your results/observations here. Good to see things working as expected.
Do note that if you see more system integration and more EDMA usage for any other peripheral or memory servicing, you could run into similar issues ( as with the concurrency of TX servicing etc), so keep an eye on this.
It is always better to keep McASP (real time) traffic on a dedicated queue-TC and not use it for any other transfers whenever feasible so that you don't run into head of line blocking etc. Additionally always better to keep the McASP traffice isolated as much as possible - in your case if you are using L2 as the src/destination, for other traffic you can use Shared RAM and DDR etc, if possible and assuming it doesn't mess up your power budget etc.

All the best.
Regards
Mukul