Thingy91: Process to flash s340 and 52840

[Brett]

Hi,

I have been doing my development on the 9160DK and now its time to move the code over to the thingy 91.  I managed to get the 9160 flashed by following (https://devzone.nordicsemi.com/guides/cellular-iot-guides/b/getting-started-cellular/posts/how-to-program-any-project-to-the-thingy-91-with-dfu), but the 52840 and s340 softdevice seem to be a different story.

I  tried to follow, without success:
https://infocenter.nordicsemi.com/index.jsp?topic=%2Fug_thingy91_gsg%2FUG%2Fthingy91_gsg%2Fupdating_fw.html

What I am not sure or have tried:
* Do I need to have the SWD-Select on nRF52, before I power-up (whilst holding sw4) ?  I saw one document indicating you needed to, but the above doesnt indicate you need to.  (I tried both)

* The image starts to load, but then I get the `Image Upload Failed: Bad response from device`.  I got the same error with the 9160, but by following the DFU link above, got around the problem - I am not sure how to get around it with the 52840, since I am not using zephyr.

* My 52840 software is using ANT+ therefore, I require the s340 softdevice and am using the legacy nRF5 SDK - since its not supported in zephyr.  The original way to load the s340 was with `nrfjprog` but that doesnt seem to work.

* For the 52840, do I need to use an external connection - say the 9160dk to be able to flash it ?

regards
-brett

[Albrecht Markus Schellenberger]

Hello Brett,

Brett said:

Its only when I load them both together I am unable to test, as I cant connect to the 9160 interface for debugging.

Thanks a lot for the detailed feedback! Are you possibly using P.014 and/or P0.17 in your nRF52840 application?

Regards,

Markus

[Brett]

Hi Markus:

Yes I am, thats how I was connecting UART's between the 52840 and the 9160.  I gather based on your question, I need to use different pins in the thingy vs the 9160DK.

52840:

nrf_libuarte_async_config_t nrf_libuarte_async_config = {
      .tx_pin = 17,
      .rx_pin = 20,
      .baudrate = NRF_UARTE_BAUDRATE_115200,
      .parity = NRF_UARTE_PARITY_EXCLUDED,
      .hwfc = NRF_UARTE_HWFC_DISABLED,
      .timeout_us = 100,
      .int_prio = APP_IRQ_PRIORITY_LOW};

9160:

&uart1 {
        compatible = "nordic,nrf-uarte";
        status = "okay";
        current-speed = <115200>;
    hw-flow-control;
        tx-pin = <18>;
        rx-pin = <17>;
        rts-pin = <19>;
        cts-pin = <21>;
}:

regards
-brett

[Albrecht Markus Schellenberger]

Hello Brett,

Brett said:

Yes I am, thats how I was connecting UART's between the 52840 and the 9160.  I gather based on your question, I need to use different pins in the thingy vs the 9160DK.

Yes, this is my theory at least :-) See, the SWD interface can also be controlled by the nRF52840, as explained here.

And according to the Thingy:91 pin mapping, P0.14 and P0.17 of the nRF52840 are assigned to the nRF9160 SWD interface data/control line.

P0.14	IF_SWD_IO	nRF9160 SWD interface data line
P0.17	IF_SWD_CTRL	nRF9160 SWD interface control

So what I think happens here is that your nRF52840 application interferes the nRF9160 SWD interface control line and causes the trouble your are currently facing.

However, in order to establish a proper UART connection between the nRF9160 &nRF52840, you might need to change the pin configuration anyway. The pictures below provide you with an overview of which pins you can choose from, respectively. They are taken from the latest Thingy:91 schematic and PCB layout file, which can be downloaded here.

          

Regards,

Markus

[Brett]

Hi Markus,

Thank You !!

That was the answer, I should have RTM - it was all there - code runs now as it does on the 9160 DK.

In the end:
52840:

.tx_pin = 25,
.rx_pin = 32,

9160:
&uart1 {
        compatible = "nordic,nrf-uarte";
        status = "okay";
        current-speed = <115200>;
    hw-flow-control;
        tx-pin = <22>;
        rx-pin = <23>;
        rts-pin = <24>;
        cts-pin = <25>;
};

regards
-brett

[Albrecht Markus Schellenberger]

Brett said:

Thank You !!

That was the answer, I should have RTM - it was all there - code runs now as it does on the 9160 DK.

My pleasure, Brett! I’m glad to hear that it works now :-)

Cheers,

Markus