Hello. I’m trying to make a power saving application. So, I use dwt_entersleep with dwt_configuresleepcnt(link_sleep_cnt). the value for link_sleep_cnt is 2. This count down register has a very coarse resolution, around 328 ms. Nevertheless, I have 1 second period so I’m making tests.
I have the RST line monitorized by an oscilloscope, so I can see when the DW1000 is slept, and theoretically when the clocks are stabilized (when RST line is up again).
The problem I have is that in one cycle it works ok, but in the next one the status_register has the SYS_STATUS_CLKPLL_LL bit set (that means that there is some problem with the PLL clock). In the third cycle it works ok again, and so each time changing the result.
The point is that if the RST line is up, why is there problems with PLL clock? If there were something wrong with configuration or hardware, it will not be so regular.
Anybody has a clue of what is happening?
Thanks in advance, regards.
I’ve used the normal sleep, waking up the dw1000 lowering the NSS pin for 700 us, and the result si the same. The next time the reading from dw1000 fails. The status reg gives CLKPLL error or 0xffffffff. I will make a simpler program to see whats happening. In the meanwhile anybody has a clue?
Are you reading too early? You should wait for RSTn line to come up, then wait another 50 us for AON configuration to download, then read over SPI. If you read too early you may be reading while the device is still in sleep
Thanks Zoran. I think I wait enough time. Here is the code that sleeps the dw1000 and then awakens it.
} else if (to_sleep) {
to_sleep = false;
dwt_entersleep();
HAL_Delay(myTag.link_sleep_ms);
awake_SPI();
}
The code for awakening the dw1000 is:
void awake_SPI(void){
HAL_GPIO_WritePin(DW_NSS_GPIO_Port, DW_NSS_Pin, GPIO_PIN_RESET);
usleep(600);
HAL_GPIO_WritePin(DW_NSS_GPIO_Port, DW_NSS_Pin, GPIO_PIN_SET);
while (! (HAL_GPIO_ReadPin(DW_RESET_GPIO_Port, DW_RESET_Pin)) );
usleep(300);
dwt_spicswakeup(dummy_buffer, DUMMY_BUFFER_LEN);
}
I pull down SPI_CS pin for 600 us. Then I wait to RST pin to be high. Then I wait again for 300 us.
Then I use dwt_spicswakeup with a 1500 bytes buffer (18MBits/8 x 667 us = 1500 bytes. I use here the dwt_spicswakeup, because if I use directly this function I get a HardFault error in HAL_SPI_TransmitReceive (called from readfromspi()). I’ using CubeMX with a STM32F103C8, but I’m moving to a STM32L432. Nevertheless these problems are with the STM32F103.
With this code and debugging step by step (so the time from RST up is very big) I still get CLOCK_PLL error the next time I RX instead of Timeout.
Is there anything regarding sleep and waking up the dw1000 I’m not aware of?
Is there a problem with HAL library?
Thanks for your help
After this:
HAL_GPIO_WritePin(DW_NSS_GPIO_Port, DW_NSS_Pin, GPIO_PIN_RESET);
usleep(600);
HAL_GPIO_WritePin(DW_NSS_GPIO_Port, DW_NSS_Pin, GPIO_PIN_SET);
while (! (HAL_GPIO_ReadPin(DW_RESET_GPIO_Port, DW_RESET_Pin)) );
usleep(300);
the device should be awake … the dwt_spicswakeup should return without doing the long read, as the dwt_readdevid should return 0xdeca0130.
I would not worry about PLL_LL flag. Can you TX/RX ok? The PLL_LL flag could have been set momentarily but will not clear unless you clear it. So if you see it, it does not mean that the PLL is not working correctly.
Z
Thanks Zoran!! You were right, if this flag is discarded it goes smooth.