Hi,
我们有boards with the DA14580 soldered on it. Default consumption seems to be around several hundred of µA which is an issue for us until we end up having a fully working BLE application. So is there any way to lower that consumption down to a few µA without burning the OTP (we can drive the chip via TX/RX or reset pin) ? What is the chip exactly doing at this stage?
Thanks in advance for your help.
Loic
Hi Loic,
The chip is busy looking for executable application code at this stage, and will be doing this continuosly until you either power it off or serve it application code via SPI, UART or I2C. You have a few options:
1. Implement a secondary bootloader in OTP. This has a couple of advantages because it allows you to also specify exactly how and when to load application code. The secondary boot loader could force the chip into deep sleep (at about 600nA) until some external event or a timer triggers a wakeup.
2. Load application code via UART that keeps the chip in deep sleep until you are ready to run or load the actual application code.
Hello Smarly, I presume these are complerely blank devices ? can you tell me if you have any access to any hardware i/o ports on the device .
On power up, if the device detects that no OTP is programmed, it goes into development mode. Here it uses SRAM for memory . On boot up, It will automatically scan the GPIO to see it it can boot from UART/SPI/i2C and loop around this 5 times. If it does not detect that, it will enable JTAG and wait.
I will check wtih the team , but i suspect the only way to do program will be through JTAG . If you can tell me what i/o you have access to, i can check to see if there are any other things to be done.
BR
JE_Dialog
Hello Smarly, I presume these are complerely blank devices ? can you tell me if you have any access to any hardware i/o ports on the device .
On power up, if the device detects that no OTP is programmed, it goes into development mode. Here it uses SRAM for memory . On boot up, It will automatically scan the GPIO to see it it can boot from UART/SPI/i2C and loop around this 5 times. If it does not detect that, it will enable JTAG and wait.
I will check wtih the team , but i suspect the only way to do program will be through JTAG . If you can tell me what i/o you have access to, i can check to see if there are any other things to be done.
BR
JE_Dialog
Hi,
Thanks for your answers! Yes these are completely blank device. We have an external access to JTAG pins, access to the UART from our processor and we can drive the reset pin. We can't turn VDD off. The best thing for us would be to send something on the UART to turn the chip off. Burning the OTP could be done on some boards but we would prefer to avoid it if possible.
How long does the 5 times loop takes? Because both the chip and our processor will start up at the same time so if our booting takes more time than the loop, we will never be able to send anything on the UART before it goes into JTAG mode anyway...
Thanks again.
Loic
I guess the secondary bootloader implementation is the answer to my questions so I'll look that way!