peripheral_lbs_DFU nRF5340-DK sending time out

Hi,

NCS1.9.99, VSCode, peripheral_lbs_DFU

nRF5340-DK   DFU got error:

3463.peripheral_lbs_DFU.7z

IOS sending time out,   android apk i have not fond.

     

Best regards

Parents
  • Hi,

    I built your project against SDK v2.0.0, but was not able to replicate the error. Could you try the same?

    Note: I had to remove these struct elements to build your project:

    Thanks,

    Vidar

    Edit: here is the update image I used: 5684.app_update.bin

  • Hi,

    thank you very much,

    i remove tow line,the same "sending time out".

    and as follow is a Simpler example, it work well in NCS1.9.1,

    but in NCS1.9.99 the same error   "sending time out".

    hello_world_dfu.rar

    i don't know why!

       

    Best regards

  • Hi,

    Please consider working with a stable release tag instead. Excerpt from the documentation regarding use of the main branch:

    "The main branch of the sdk-nrf repository always contains the latest development state of the nRF Connect SDK. Since all development is done openly, you can use it if you are not particularly concerned about stability and want to track the latest changes that are being merged continuously into the different repositories." https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/dm_code_base.html#revisions

    yoyou said:
    because set pin by another psels

    This is covered in the migration document here: https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/migration/migration_guide_1.x_to_2.x.html#ncs-2-0-0-migration

    yoyou said:

    ios phone sending time out.

    even ios app i've remove and reinstll it.

    In case the iphone may have stale bonding information stored for your peripheral, you may try to go tho the device list in settings->bluetooth and forget your peripheral device if it is listed, then turn Bluetooth off and on before you attempt DFU again.

  • Hi

    thanks for reply,

    i have reinstall 2.0.2.

    nrf5340dk_nrf5340_cpuapp  i2s build.

    (1) how to disable i2s SDIN pin?

    it can't set to 0xFF,  no set means disable?

    &pinctrl {
    	spi3_default: spi3_default {
    		phandle = < 0xa >;
    		group1 {
    			psels = <NRF_PSEL(SPIM_SCK, 0, 0x1f)>,
    			<NRF_PSEL(SPIM_MISO, 1, 0x00)>,
    			<NRF_PSEL(SPIM_MOSI, 1, 0x0d)>;
    			// <NRF_PSEL(SPIS_CSN, 0, 0x0f)>;
    		};
    	};
    	spi3_sleep: spi3_sleep {
    		phandle = < 0xb >;
    		group1 {
    			psels = <NRF_PSEL(SPIM_SCK, 0, 0x1f)>,
    			<NRF_PSEL(SPIM_MISO, 1, 0x00)>,
    			<NRF_PSEL(SPIM_MOSI, 1, 0x0d)>;
    			// <NRF_PSEL(SPIS_CSN, 0, 0x0f)>;
    			low-power-enable;
    		};
    	};
    
    	i2s0_default_alt: i2s0_default_alt {
    		group1 {
    			psels = <NRF_PSEL(I2S_SCK_S, 0, 0X19)>,
    					<NRF_PSEL(I2S_LRCK_S, 1, 0X18)>,
    					<NRF_PSEL(I2S_SDOUT, 0, 0X08)>,
    					<NRF_PSEL(I2S_SDIN, 1, 0x07)>;
    		};
    	};
    	
    };
    &spi3 {
        compatible = "nordic,nrf-spim";
        label = "SPI_3";
        status = "okay";
    	cs-gpios = < &gpio0 0x10 0x1 >;
    	pinctrl-0 = < &spi3_default >;
    	pinctrl-1 = < &spi3_sleep >;
    	pinctrl-names = "default", "sleep";
    };

    (2)  in NCS1.9.99- get i2s pin number from overlay note as follow line:

    DT_PROP(DT_NODELABEL(i2s0), mck_pin)

    how to get i2s pin number in NCS2.0.2?

    (3) DeviceManage app DFU error "sending time out" on IOS,

    but work well on Android. maybe Nordic should update IOS app.

    tips: IOS phone had forget peripheral device , then close Bluetooth and restart,

    and then restart phone, and then reinstall app.

                    

    Thanks  !

    Best regards

  • Hi,

    Sorry for the delayed response.

    1) Setting the pin as unused is currently not supported through the pinctrl API. You will however achieve the same if you omit  i2s SDIN pin definition your devicetree like you suggested.

    2) With pinctrl enabled you need to use the pinctrl_apply_state() to configure the i2s psel registers as shown here: https://github.com/nrfconnect/sdk-zephyr/blob/482dcc7865f7d3a458f061a1d8276c5801eed1e4/drivers/i2s/i2s_nrfx.c#L899 and init the driver with .nrfx_def_cfg.skip_gpio_cfg = true and .nrfx_def_cfg.skip_psel_cfg = true.

    3) Did you test this with SDK v2.0.2?

  • Hi,

    (1)about get pin number,

    i want to get i2s pin number in source code,as follow line

    int pin = NRF_DT_GPIOS_TO_PSEL(DT_NODELABEL(button0)
    but don't konw how to get it in NCS2.0.2.

    (2)about DFU time out,

    yes, i test with SDK v2.0.2.

    I said before, it work well in android, because 5340App only run DFU ota in main.

    void main(void)
    {
        printk("Hello World!\n" );
        ota();
    }
    when i add button enter DFU ota,
    it show "time out" in android and IOS,
    void main(void)
    {
        printk("Hello World!\n" );
        init_button_led();

        while(true){
            if(will_ota) ota();
            else k_msleep(100);
        }
    }
    because DFU finshed and restart 5340 device,
    phone app need connect 5340 device again,
    if can't connect will show "time out", DFU failed.
         
    i button again enter DFU when DFU finshed and restart 5340 device,
    it will connect ok and show "complete",DFU success.
         
    it means must bt_le_adv_start(...) for phone app connect  when DFU finshed and restart 5340 device.
    why?  Is it the defect of NCS?
    My app doesn't use Bluetooth, except for upgrading DFU.
    bt_le_adv_start(...)  again means more complicated.
           
    Best regards
  • Hi,

    1) You should not have to read the pin numbers from the application when pinctrl is used. That is the intention with the design, at least. But if you have to, then you can use the internal NRF_* macros as shown in the pinctrl test code. These can be used to decode the  structure returned by PINCTRL_DT_DEV_CONFIG_GET().

    https://github.com/nrfconnect/sdk-zephyr/blob/main/tests/drivers/pinctrl/nrf/src/main.c

    2) Thanks for the clarification. Just so to confirm I understand it correctly, does this mean that DFU works now, and the only problem being that the device manager app is "wrongfully" reporting "time out" after an successful update?

Reply Children
  • Hi,

    thanks for reply,

    1) 

    i2s_rxtx: &i2s0 {
    	status = "okay";
    	pinctrl-0 = <&i2s0_default_alt>;
    	pinctrl-names = "default";
    };
    &pinctrl {
    	i2s0_default_alt: i2s0_default_alt {
    		group1 {
    			psels = <NRF_PSEL(I2S_SCK_S, 0, 0X15)>,
    					<NRF_PSEL(I2S_LRCK_S, 1, 0X08)>,
    					<NRF_PSEL(I2S_SDOUT, 0, 0X13)>;
    					// <NRF_PSEL(I2S_SDIN, 0, 0xFF)>;
    		};
    	};
    	
    };

        struct pinctrl_dev_config *pcfg = PINCTRL_DT_DEV_CONFIG_GET(DT_NODELABEL(i2s0));
        const struct pinctrl_state* scfg = &pcfg->states[0];
        int pin0=NRF_GET_PIN(scfg->pins[0]);
    drivers\pinctrl.h:99:10: error: '__pinctrl_dev_config__device_dts_ord_DT_N_NODELABEL_test_device_ORD' undeclared here (not in a function)

    2)yes,it works now,

    device manager app is not "wrongfully" reporting "time out" after an successful update.

    time out means not successful update. it will RollBACK swap.

    Steps I guess:

    1.manager app connect to 5340,

    2.manager app upload data,

    3.5340 swap data,

    4.5340 sys_reboot,No mark complete in mcu flash.

    5.manager app connect again for confirm. 5340 will mark complete in mcu flash.

    6.manager app get respond will show "complete ".

        

    NCS1.9 This problem will not occur, don't need connect again.

    maybe 5340 mark complete in step4, and respond to device manager app for show complete.

    please check the problem is SDK bug?

      

    Best regards

  • Hi,

    1) PINCTRL_DT_DEV_CONFIG_GET(DT_NODELABEL(i2s0)); should not expand to The__pinctrl_dev_config__device_dts_ord_DT_N_NODELABEL_test_device_ORD. Please make sure you are not using the macro with "test_device" as in the sample linked to.

    2) This sounds like the correct behavior, the bootloader will roll back to the previous image if the update does not get confirmed. But you don't need to confirm it over BLE (which will lead to a timeout in your case). You can do a "confirm only" update instead of "test and confirm", or you can call img_mgmt_state_confirm() from the new application after it has booted up.

  • Hi,

    thank you very much,

    do  "confirm only"  that ok,

    not need connect again.

      

    Best regards

Related