Hi,
I am Using nrf58210 ,i have connected 2.85V as VCC, as i m controlling some LEds through GPIO and Leds are sinking more current, thats why the MCU stays in Boot mode.
Is there any way i can change the output Voltage of the GPIO. I came to this conclusion because when i connect 2.5V as Vcc the MCU runs the Application code normally.
Hi,
There is no way to configure the GPIO pin voltage on the nRF52810. The GPIO voltage will be the same as your supply voltage.
Perhaps if you elaborate a bit more on the problem we can see if we can think of another way around the issue you are seeing?
Hi Einar,
Thanks for the prompt reply,
yes, I can elaborate on the problem in Detail. so after the Application code flashing, the MCU broadcasts but stays in the boot mode attached is the video of that. Even if we perform DFU it doesn't change its Broadcast name which we have set after the DFU Update.
We have produced 2000pcs and the tests were passed so all of the products are not showing problem at the start but after some time they stuck at the boot mode.
Normally when the board starts it blinks 4 red, 4 yellow and 4 orange respectively.
so i have noticed on other thing, it is random, sometimes the controller comes out of boot mode and sometime not, i want to know what is the power on cycle of the MCU, i think if we turn of the GPIOs at start so that no LED turns on at the start then it could work?
After a reset the GPIO's are all disconnected inputs (so high impedance) and will remain that way until configured differently by firmware at some point after reset. The bootloader will by default configure a couple of pins though, both outputs for LEDs and an input pin for checking whether to enter DFU mode or start the application.
Do you by any chance have NRF_BL_DFU_ENTER_METHOD_BUTTON set to 1 in your bootloader's sdk_config.h? If so, what is NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN set to? And what is that pin used for on your board? If you don't intend to have a pin to enter DFU mode, you should set NRF_BL_DFU_ENTER_METHOD_BUTTON to 0. Or alternatively, set NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN to the correct pin for your HW.
Hi Einar,
I have made the above changes and tried on the dev board the LEDS are not set but when I generate the DFU file, unfortunately, i cannot perform OTA, nrf connect gives an error Insufficient resources.
I think the previous developer developed the Application code using an older version of SDK and now I am comüiling in with SDK 17 may be it a problem.
Can you please tell me what I am doing wrong here?
so, i saw NRF_BL_DFU_ENTER_METHOD_BUTTON was set to one in Bootloader code and NRF_BL_DFU_ENTER_METHOD_BUTTON_PIN was set to P 0.16 where i have LED. Now i have disabled all.
raza22 said:I think the previous developer developed the Application code using an older version of SDK and now I am comüiling in with SDK 17 may be it a problem.
Can you please tell me what I am doing wrong here?
Then that is the problem. For doing the change I suggest, take the original bootloader project used in your product (the exact one that you have running) and original SDK (whichever that was), and rebuild. As long as you only make the change I suggested, there is no problem. The size will not increase with this change.
Generally, you need to know what is running on the device, so if there is an issue with the device staying in bootloader mode, you need to get hold of the source for for the bootloader that is running. If not, you will be working more or less in blind.
raza22 said:I think the previous developer developed the Application code using an older version of SDK and now I am comüiling in with SDK 17 may be it a problem.
Can you please tell me what I am doing wrong here?
Then that is the problem. For doing the change I suggest, take the original bootloader project used in your product (the exact one that you have running) and original SDK (whichever that was), and rebuild. As long as you only make the change I suggested, there is no problem. The size will not increase with this change.
Generally, you need to know what is running on the device, so if there is an issue with the device staying in bootloader mode, you need to get hold of the source for for the bootloader that is running. If not, you will be working more or less in blind.
yws you are right.
Is there any way to read the previous hex of DFU file to check which SDK version was used?
No, that is not possible. Do you have some of the code, like the bootloader project and application project, even though you don't have the full SDK? If so, and if that was based on SDK code, perhaps you can narrow it down by looking at the years in the copyright notice in the top of the files, and/or look for other parts that changed in different SDK versions. Or perhaps there is some documentation in your company that you can find that describes this? Generally, I would think it strange to not document these things.
Yes, i have the code. unfortunately, it was not documented and the handover was also not appropriate
can you help me with that, i am attaching zip files in the thread can you please help me finding this out.
i am attaching Bootloader and App code. gt7_secure_bootloader-master.zipgt7_ble_app-master (5).zip
Hi,
I see, then you have a suboptimal starting point. But we should be able to narrow this down.
The copyright notice in sdk_config.h in the bootloader project says 2017 - 2019, so that points to SDK version 15.3 og 16.0.0 (though we have no guarantee that it has not been ported to a later SDK while keeping parts of the file). From the project files I see that liboberon_3.0.1.a is used, which is the version used in SDK 16.0.0. The SoftDevice version (7.0.1) also match what was used in SDK 16.0.0 and 17.0.0, so there is good reason to think this project was made with SDK 16.0.0.
Hi Einar,
thanks for you support, i solved the problem by disabling that NRF_BL_DFU_ENTER_METHOD_BUTTON in Boaoloader sdkconfig and doing OTA only for Bootloader
