• State Verified Answer
  • Replies 13 replies
  • Subscribers 74 subscribers
  • Views 2330 views
  • Users 0 members are here
Attachments (4) Download All
Nordic Case Info
  • Case ID: 302875
Options

GPIO Output Voltage

raza22

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. 


Parents
  • 0

    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?

  • 0 in reply to Einar Thorsrud

    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. 

  • 0 in reply to raza22
    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.

  • 0 in reply to Einar Thorsrud

    yws you are right.
    Is there any way to read the previous hex of DFU file to check which SDK version was used?

  • 0 in reply to raza22

    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.

  • 0 in reply to Einar Thorsrud

    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 

  • +1 in reply to raza22

    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.

Reply
  • +1 in reply to raza22

    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.

Children
Related
Terms of service