I am running AT-Commands over SPI on the DA16600 module. Some of the AT-Commands don't work.
AT+WFMODE=0, AT+WFSTA, AT+WFSCAN and other network related commands do not work.
I am sending;
AT+VER, AT+TMRFNOINIT=0, AT+WFSCAN, AT+WFMODE=0 and, AT+WFSTA [in order]. I have enabled 'DEBUG_ATCMD' from the SDK and this is the output I see,
There is no AT-Command executed after AT+TMRFNOINIT=0.
For AT+TMRFNOINIT=0 and rest, the response from buffer is overlapping the header message sent by the main MCU [refer the logic analyzer output].
What is going on here? how to fix this?
I have attached the logic analyzer file containing SPI signals for each command. [they are shown in order]
spi at command signal output.zip
Note: The modifications to the SDK are as per the documentations.
Hi There,Apologies for the delay.From the logic trace, we can see that the host is not reading the DA16200's response in time.Could you check if you are reading the response as soon as possible after the DA16200's SPI interrupt occrus?In the SDK, there is a 200ms timeout for reading the data from the host. If the MCU does not read the response from the DA16200 in time, it will be dropped.
This is described in section 3.2.2.3 Read Sequence and Structure from the UM-WI-003 DA16200 DA16600 Host Interface and AT Command User Manual (renesas.com)Best Regards,OV_Renesas
Hello,
Sorry for the delay in my response,
We have developed a custom board for DA16600, and the SPI interrupt is assigned to a non-IRQ pin on the main MCU, so I cannot use interrupts to detect the signal sent from DA16600.
There are three options for me, as I see it;
1. Increase the pulse-width of SPI-interrupt generated from DA16600 as I am using a while loop to continuously read the pin and detect a change in level.
2. Change the SPI-interrupt to another pin on DA16600. [here, I am able to change the SPI-interrupt to another GPIO from SDK, but as per our hardware design I can only swap the functionalities of SPI-interrupt with RTC_GPO to fit our MCU, please give me a direction on how to do this!]
3. Add interrupt functionality to a non-IRQ pin on main MCU [S7G2 in our case], which I know is not a good option.
What do you suggest I do? if you have any better insights, please share!
Thank you.
Hi There,Thank you for the reply.Let me check on this with the Wi-Fi team and I will get back to you as soon as possible.Best Regards,OV_Renesas
Any updates on the above issue? did you find a suitable solution?
Best Regards,
synd223
Hi Synd223.Apologies for the delay.I do not have any update yet. I will try to update you tomorrow.Best Regards,OV_Renesas
Hi Synd223,Apologies for the delay.We have confirmed that options 1 and 2 can be used with some modifications to the SDK. These depend on the performance of the MCU, so you should choose the best way after verification.Regarding Option 1:To increase the pulse width of the SPI interrupt the following change is required. With this change the pulse width will be 135us which is the maximum:
void host_spi_slave_init(void) { ... // Pulse duration:0x3F(135us), Edge mode:0x01, Active high:0x01 DA16X_DIOCFG->EXT_INTB_CTRL = 0xFF; ... }
void host_spi_slave_init(void) { ... // Level mode:0x00, Active high:0x01 DA16X_DIOCFG->EXT_INTB_CTRL = 0x01; ... } { ... DA16X_DIOCFG->EXT_INTB_SET = 0x1; // Trigger Host Int (GPIO ) // Level mode if ((DA16X_DIOCFG->EXT_INTB_CTRL & 0x10) == 0) { SYSUSLEEP(1000); // 1ms DA16X_DIOCFG->EXT_INTB_SET = 0x0; } ... }
Regarding Option 2:Note that the default function of the RTC_GPO is flash control. So the pins will be high at boot-up.To change the SPI interrupt to RTC_GPO, the following modifications are required:
int config_pin_mux(void) { ... RTC_GPO_OUT_INIT(1); // 0: auto, 1: manual RTC_GPO_OUT_CONTROL(0); }
RTC_GPO_OUT_INIT(1); // 0: auto, 1: manual RTC_GPO_OUT_CONTROL(1); SYSUSLEEP(1000); // 1ms RTC_GPO_OUT_CONTROL(0);
TO test the case option 1, you can choose the interrupt with the following macro:
#define CFG_CUSTOM_HOST_INTERRIPT_MODE (1) // 0: Level mode, 1: Edge mode
#define CFG_USE_RTC_GPO_AS_HOST_INT (1) // Using RTC_GPO as the host interrupt pin
previously, I made a mistake of assigning the SPI-interrupt to a non-IRQ pin on the main MCU [S7G2 in my case]. I made the hardware modifications and IRQ works as expected. But this AT-commands response issue persists.
I have attached the logic_trace and debug logs, please refer the same and advice on next steps.
F.Y.I. In the logic_trace, after 'AT+WFCC', I tried to send 'AT+WFMODE=0' and if we observe, there is no response from DA16600, the interrupt is not triggered.
Please give me an update on how to resolve this error.
The WiFi SDK firmware version: DA16200_DA16600_SDK_FreeRTOS_v3.2.8.1
Modifications to SDK: As suggested in the documentation [UM-WI-003], additional to this,
1. I have disabled all the examples
2. I have modified the pin_mux to fit our design
signal_trace and log.zip
Hi Synd223,Thank you for the reply.I have escalated this to the Wi-Fi Support Team and I will get back to you as soon as possible.Note: For any other issues, please open/create a new ticket so we can follow up easier each issue separately.Best Regards,OV_Renesas
Hi Synd223,We checked the SPI capture and found somethings.Here is the details:1. In the Write Request, there was unexpected AT command data. Please check the white colored box in the screenshot. If the Length(3bytes) of the AT command (4bytes aligned) was 0x0C (12bytes), the following AT command data should be 12 bytes. But, the following AT command data was greater than 12 bytes.
2. In the Read Response, the Length was 0x0C (Red box). It should be 0x08 (8 bytes = Buffer Address(4) + Buffer Length(2) + Response(1) + Padding(1). And, in here, DA16200 sent the Length (0x08 0x00 -> 8bytes(little endian)) of the Read Data as following sequence (White box)3. In the Read Data part, the Length was 0x06. It should be 0x08 (white box). Because DA16200 sent the length 0x08 at the previous Read Response sequence (#2).4. At last, in the SPI interrupt- Read Response - Read Data. The interval between Read Response and Read Data was around 219.6us. Please increase the interval to > 300us. The AT command guide describes it:
Seems that response of the 'AT+WFCC' did not work due to incorrect values. (Length and Data). Then, it affect to the following AT+WFMODE=0 command.Please check our findings and share any follow-up questions.Best Regards,OV_Renesas
Hi OV_Renesas,
After making the suggested modifications, I am able to read the response correctly.
major issue with my approach was with my misunderstanding of the following entry in Um_WI-003,
I assumed the buffer_length is only the actual data_length and padding should be removed. hence, the length is 0x06 here,
I made the modifications, it works fine now!
I have another issue with few commands, but it is unrelated to this topic, I will open a new ticket.
Thank you so much for a quick response, I really appreciate it.
Best regards,