Hi all,
I face a problem when using the DSPS project,I disable the default HW & SW flow
control definition,and use a gpio for the MCU to wakeup the DA14580.My problem is the
uart received data is wrong,but byte count is right.Some times, the data may be right
too.(when disable the extend-sleep mode,the data is allways right)
eg:
when I send 0x00, then I get 0x80;when I send 0x55,then I get 0xAD.
我相信DA14580睡醒了,不花er sleep unitl the gpio changes
level.
When DA1480 is waked up,I re-init the pad and uart,using periph_init() function.and
the callback funtion is based on the push button callback of the demo project
(reportor).
I tried to send some dummy bytes data, but this method does not work well.
I also tried to increase the delay between the GPIO level change and the data
stream. only when the delay is as long as the connection interval,data seems to be
right.This is a bad method because the MCU and DA can not sleep for long.
should I change the software structure ?or the configuration of the uart? or change
the wake up callback?
任何的建议会不胜感激!
Hi birenpeter,
In order for the UART to work properly it requires the XTAL16 for proper clocking, when waking up from sleep via an external interrupt there is no switching to the XTAL16, not until a BLE event is triggered and the BLE is forced to wake up. So when waking up from an external interrupt your UART is functioning via the RC16 (not accurate enough to get valid data from your UART). So when waking up you will have to invoke the arch_ble_force_wakeup in order to wake up your BLE and switch to XTAL16. Also for waking up the BLE core, switching clocks and waiting for the XTAL16 to settle requires some time (about 5ms) so you will have to either delay sending data from your MCU or trigger your external MCU with an other pin that the 580 is awake, so its safe to start sending data.
Thanks MT_dialog
Many thanks! The DSPS can receive data exactly now! and the current is right.My method is stated below!
In my wakeup callback,I manually enable the XTAL16M and set as system clk, then force ble powered.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
void gpio_wakeup_callback(void)
{
//re-init periph
periph_init();
SetBits16(CLK_CTRL_EG,TXAL16M_DISABLE,0);//enable the XTAL16M
while((GetWord16(SYS_STAT_REG)&XTAL16_SETTLED)==0);//wait for ready
SetBits16(CLK_CTRL_REG,SYS_CLK_SEL,0);//set XTAL16M as sys clk
while((GetWord16(CLK_CTRL_REG)&RUNNING_AT_XTAL16M)==0);//wait for ready
arch_ble_force_wakeup();//force ble wakeup
....
//re-init wakeup
gpio_wakeup_init();
}
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
In mainloop call back functions user_on_system_powered(),I check the ble and the XTAL16M state,and notify the MCU.
//////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
enum user_on_system_powered(void)
{
.....//check buffer
if(ble_is_powered())// check wether ble is powered
{
if(GetWord16(SYS_STAT_REG)&XTAL16_SETTLED)!=0) &&((GetWord16(CLK_CTRL_REG)&RUNNING_AT_XTAL16M)!=0)
{
//toggle another gpio to notify the MCU,DA is ready to receive data.
....
}
}
}
////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Although it is workong well now,there are some questions I am not sure.
1.In arch_ble_force_wakeup(),there is not any operation on XTAL16M. Is it the exact reason for receiving wrong data before?Is it suggested to manually turn
on the XTAL16? Will it make the software unstable?I also don't know where the XTAL16M is closed.
2.I test the time-window from wakeup to notify MCU,It is about 4~6ms in connection state,but it is 100~200us in advertising state.I don't know why.
3.For special purpose,I replaced the TX(read,notify) and RX(writewithoutresponse) character with a single character DATA(read,writewithoutresponse,notify),
when DA14580 is continously sending notify(about 5KB/s),the Phone App write some bytes to DATA character.DA14580 can rightly get the writed data,while the
PhoneApp变得如此me wrong notified data. DA14580 does not support binary direction transmition at the same time?
Hi birenpeter,
1. The arch_ble_force_wakeup() doesn't switch the crystal to the XTAL16, it just triggers the BLE wakeup functionallity, after you ve used that function (arch_ble_force_wakeup()) the LP and SLP Handlers should be called and in the SLP handler is where the XTAL16 crystal switches. So normally by just calling the arch_ble_force_wakeup() your device's XTAL16 should ready and you dont have to explictly switch clocks in your wake up function. The problem is that when you invoke the BLE force wake up the LP handler doesn't get invoked immidiatelly. The XTAL is closed in the main loop function in arch_go_to_sleep() function, there the system changes from the XTAL16 to the RC16.
2. 100~200us is a very small time for the LP and the SLP to get executed.
3. It sounds a bit weird that you get data corrupted by BLE transfer, i suppose that the CRC would save you from that situation most of the times, perhaps not always (not sure about that). But yes you can transfer data from slave to master and from master to slave at the same time, the master always sends an empty packet to the slave during a connection interval and the slave responds, instead of empty packets the devices are exchanging data.
Thanks MT_dialog