IWR1443: minimizing power consumption - questions

Hi Akash,

yes, of course we know the official power optimization design. This is implemented already on our end, but further reduction of power consumption would be needed in our application.

Could you advise on the questions 1 and 2?

Thank you.

Hi Bart

For question 1, the UART stream should only be coming from the external MCU not from the IWR1443 device. Can you elaborate more on what you are seeing?

For question 2, this isn't possible. Rather the solution is the power switching mechanism discussed in my post above. This is implemented in the TIDEP-0091 but programming the PMIC is performed by the external MCU (MSP432), so customer may not have implemented it yet.

Regards,

AG

Hi Akash,

My name is Gabor Benyhe. I am working on the same project what Bart mentioned. Thanks for your reply, of course we checked the TIDEP0091 design guide, and could get under 20 mJ in our design, but still seeking for further possibilities of energy reduction. One idea is to check whether the boot time could be somehow shortened. I have noticed, that for example if I do not use the CLI it also shortens the system boot time by a few hundreds of microsecs. I also noticed, that there is a data stream appearing on the UART at 115kbps during booting. Do you know the purpose of this data stream? It appears to have some short header-like part, than blocks containing \x00\xfa\x71 come periodically, with almost exactly 424 microseconds between each block, then some closing block at the end of booting. Could this data sending be somehow switched off? Of course switching it off would not necessarily shorten the boot time, but I would like to know at least the purpose of this serial data and the possibilities around it.

Best Regards

Gabor

Hi Akash,

Regarding question 1: I am entirely sure that it comes from the IWR. We are not using the demo board, we have our own PCB design. The MCU sits on a separate PCB. Even if the UART lines are disconnected from the MCU, the data is still there on pin R5 during bootup. It can be some debug firmware trace or something similar, I can only guess.

Regards:

Gabor

Hello Akash,

do you have some feedback for us based on the above details from Gabor?

Thank you.

Thank you Bart and Gabor

I am still looking into this and will need a couple of days to provide a recommendation. Aiming to have an update End of Thursday.

Regards,

AG

Hi Akash,

No problem, thanks. Let me tell you my further findings also. I noticed, that the length of this data stream during boot (let's call it as debugtrace for simplicity) varies depending on which library components does the application use. That's sort of logical. But I also noticed, that for example if I use SPI for interfacing, the length of the debugtrace is 13.2 msecs, if I use UART it becomes 13.05 msecs, and the surprising thing comes now: if I involve both SPI and UART the length of the debugtrace shortens to 10.6 msecs, which makes a significantly (about 10%) shorter total booting time.

Question 1: Is there any document dealing with this behaviour of SYSBIOS booting process?

Question 2: if this serial data is sort of a debug trace indeed, does this mean that some components include debug functionality? Maybe a release version also exists? If yes, can that be faster due to the lack of debug functionality?

Best regards

Gabor

Hello Akash,

do you have some updates for us?

Thank you.