DA16600 - SPI AT command response error

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. 

Parents Reply Children
  • 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

  • Hello,

    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;
    ...
    }

    To increase the pulse width to a longer value, change the interrupt mode to level mode and then control the interrupt manually through the following changes:
    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);
    } 

    Replace the line DA16X_DIOCFG->EXT_INTB_SET=0x1; with the following code:
        RTC_GPO_OUT_INIT(1); // 0: auto, 1: manual
        RTC_GPO_OUT_CONTROL(1);
        SYSUSLEEP(1000);    // 1ms
        RTC_GPO_OUT_CONTROL(0); 

    To help you out, I have attached the modifications that we have tried and tested.
    spi_interrupt_alternatives.zip

    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 
    

    And to test the case option 2, you can choose using the RTC_GPO as the host interrupt pin.
    #define CFG_USE_RTC_GPO_AS_HOST_INT             (1)	// Using RTC_GPO as the host interrupt pin 
    

    Please let us know if you have any problems.

    Best Regards,
    OV_Renesas

  • Hello,

    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

    Thank you.

    Best Regards,

    synd223

  • 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,

    synd223