peripheral_lbs_DFU nRF5340-DK sending time out

[yoyou]

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

[Vidar Berg]

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

[yoyou]

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

[yoyou]

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

[Vidar Berg]

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?

[yoyou]

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

[Vidar Berg]

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.

[yoyou]

Hi,

thank you very much,

do  "confirm only"  that ok,

not need connect again.

  

Best regards