Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Michael Bisbano wrote:

Hi all,

I was wondering if anyone had data on power draw for the MityDSP-L138 in deep sleep? My application is battery powered and we are determining if it is more feasible to have an external circuit on our custom baseboard control power to the SOM or if we can just use the internal RTC in the OMAP-L138 to issue a wakeup from deep sleep. Also, any help in software getting setup for the RTC and deep sleep is appreciated so that I can test as well. If someone could point me towards example code or the right resources I would appreciate it.

Hi Michael, I did a bunch of work for the MitySOM-335x for sleep mode but am not sure about the L138. I'll ask around and let you know what I find out.

The end application will likely involve the ARM core delegating work to external devices and the DSP core, and then going to sleep while waiting for an interrupt to wake. The DSP will be performing continuous signal processing on audio data from a McASP port. Any guidance on this would be helpful. I understand that DSPLINK is what people have used to establish interprocessor links, but was curious about the SYSLINK from TI that some pages talk about. Is there any advantage to SYSLINK that would warrant more development on my end to migrate to that instead of DSPLINK?

Again, low power is a huge constraint for my application, our budget is 1W.

In the meantime could you clarify this requirement? Is 1 watt your budget when in sleep more or awake? Is that for the SOM or the whole system?

Before I spend time writing code, it would be nice to have some validation that the ARM core can be put into reset or sleep while the DSP is functioning, and an interrupt issued from the DSP can be used to wake the ARM core. The TI documentation on the OMAP-L138 show very granular control over system power and configurations (Using the OMAP-L138 Power Spreadsheet), how do we access that control from LINUX on the MityDSP-L138 SOMs? The OMAP-L138 TRM speaks of the Power and Sleep Controller (PSC) module. Do we just poke those registers or is there a better way to go about it?

I would expect the kernel would handle this, though I don't know how far TI went to add support for turning off parts of the processor.

Any help or insight is appreciated. If my post is lacking information, please ask for clarification!
Thanks, Michael

Hi Jonathan,
Thank you for the response, please let me know what you find out! The system as a whole must be under 1W average while operating, and very low <50mW when in sleep. When operating, it will be performing some audio signal processing in the DSP but the ARM core would not need to be fully functional, and ideally is not clocked to save power. The system will primarily consist of the SOM, audio codecs, and audio preamplifiers. As a ballpark now, that means the SOM itself should be below 600mW. Every once in a while, a wakeup will be issued from the DSP to alert the ARM core, and the ARM core will be responsible for communication, files/logging transactions, and some general decision making.

My insight from these forums and wikis are that my application is generally inverted from the common use case of this SOM. It seems a lot of focus is on the ARM core, and the DSP core is just there for extra processing. Has anyone used these OMAP-L138 SOMs for DSP core applications? Can the ARM core be run at low power while the DSP core remains fully functional? I know this would certainly be possible with the OMAP-L138 IC, but does this SOM support it in the same manner?

With regards to the kernel, I don't know how I would go about tracking these features down. Where can documentation on the kernel be found? Is this a linux kernel supplied by TI or has CriticalLink spun up their own? I only have experience with PetaLinux on Xilinx devices (on a custom board), so this is my first time working with linux on a TI based SOM. Any learning resources or materials that help hold your hand through this process would be appreciated as well.

Thanks again,
Michael

Michael Bisbano wrote in RE: MityDSP-L138 Power Draw in Deep Sleep? Waking ARM cor...:

Hi Jonathan,
Thank you for the response, please let me know what you find out! The system as a whole must be under 1W average while operating, and very low <50mW when in sleep. When operating, it will be performing some audio signal processing in the DSP but the ARM core would not need to be fully functional, and ideally is not clocked to save power. The system will primarily consist of the SOM, audio codecs, and audio preamplifiers. As a ballpark now, that means the SOM itself should be below 600mW. Every once in a while, a wakeup will be issued from the DSP to alert the ARM core, and the ARM core will be responsible for communication, files/logging transactions, and some general decision making.

We have some posted power usage measurements for the module here: https://support.criticallink.com/redmine/projects/arm9-platforms/wiki/33V_Supply_Requirements
A max of 1W looks like it would hard to reach. The measurements don't include the baseboard power which would add some additional load. There is likely some room for optimizations like ensuring there are no floating inputs or pullups that might be in conflict but those savings are likely in the low mW range.

My insight from these forums and wikis are that my application is generally inverted from the common use case of this SOM. It seems a lot of focus is on the ARM core, and the DSP core is just there for extra processing. Has anyone used these OMAP-L138 SOMs for DSP core applications? Can the ARM core be run at low power while the DSP core remains fully functional? I know this would certainly be possible with the OMAP-L138 IC, but does this SOM support it in the same manner?

There is likely nothing on the SOM hardware that would prevent this behavior, if the L138 supports it. Though, It's not something we are used to doing.

With regards to the kernel, I don't know how I would go about tracking these features down. Where can documentation on the kernel be found? Is this a linux kernel supplied by TI or has CriticalLink spun up their own? I only have experience with PetaLinux on Xilinx devices (on a custom board), so this is my first time working with linux on a TI based SOM. Any learning resources or materials that help hold your hand through this process would be appreciated as well.

Generally, most subsystems aren't enabled if they aren't enabled in the board file.

Our sales rep should contact you to set up a meeting to help define these requirements and see if we can find a path forward.