• State Verified Answer
  • Replies 3 replies
  • Subscribers 74 subscribers
  • Views 658 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 321847
Options

Same HEX, same SoC, different results??

Brian_H

I started with the peripheral_uart example.  Not being happy with the bit rate and the 40-byte buffering in the UART-to-BLE direction, I set off to refactor the code and make it fit my needs more exactly.

I just finished a refactoring pass which should've represented no functional change, so I built it and loaded it, and things went...badly.

I'm developing for the ublox BMD-360 module, which is equipped with an nRF52811 SoC, which is built into my project, with its SWD interface exposed for programming / debugging.  I also have a ublox BMD-300 series evaluation board which is populated with the BMD-360 module as well.

I can load the exact same HEX file onto both modules and the behavior is different.  On the eval board, it runs as expected.  The one in my project crashes inside mpsl_init.

If I attach gdb, the one loaded on the eval board breaks in identifiable locations depending on the particular moment I press Ctrl-C.  The one loaded in my project invariably breaks at address 0x0000b900 and shows a corrupted stack.  If I try to single-step, eventually something happens that crashes gdb.

I have an earlier version of the code, which still runs just fine on both modules, but of course is lacking the features I want to implement.

I'm absolutely stymied by the difference in behavior across modules.  Why does one crash and another does not, when they are both loaded with the exact same binary image?

Please let me know what additional info I need to provide.  I'm coding against the zephyr SDK version 0.16.1 using west in a WSL environment (because I couldn't get the Windows toolchains set up properly).  For debugging, I'm using J-Link GDB Server in Windows, and the gdb shipped with Zephyr to do a remote target in WSL.

Any and all input is greatly appreciated.  Thanks in advance!

Parents
  • +1

    As a guide, this kind of issue is typically caused by the difference in hardware, as the development board has a 32.768kHz crystal on the board whereas the module does not unless you added one. Note the uBlox BMD-360 does not have the 32.768kHz crystal internally, it only has the 32MHz crystal.

    "3.6 Clocks The BMD-360 requires two clocks, a high frequency clock and a low frequency clock. The high frequency clock is provided on-module by a high-accuracy 32 MHz crystal as required by the nRF52811 for radio operation. The low frequency clock can be provided internally by an RC oscillator or synthesized from the fast clock, or externally by a 32.768 kHz crystal. An external crystal provides the lowest power consumption and greatest accuracy. Using the internal RC oscillator with calibration provides acceptable performance for Bluetooth low energy applications at a reduced cost and slight increase in power consumption"

    Should the absent 32.768kHz crystal indeed be the issue, the LF clock in the build must be specified as other than an external crystal otherwise chaos ensues.

    Edit: Also the stand-alone module used to be supplied with Rigado/uBlox firmware, boot stuff, which has to be erased; the development board does not.

Reply
  • +1

    As a guide, this kind of issue is typically caused by the difference in hardware, as the development board has a 32.768kHz crystal on the board whereas the module does not unless you added one. Note the uBlox BMD-360 does not have the 32.768kHz crystal internally, it only has the 32MHz crystal.

    "3.6 Clocks The BMD-360 requires two clocks, a high frequency clock and a low frequency clock. The high frequency clock is provided on-module by a high-accuracy 32 MHz crystal as required by the nRF52811 for radio operation. The low frequency clock can be provided internally by an RC oscillator or synthesized from the fast clock, or externally by a 32.768 kHz crystal. An external crystal provides the lowest power consumption and greatest accuracy. Using the internal RC oscillator with calibration provides acceptable performance for Bluetooth low energy applications at a reduced cost and slight increase in power consumption"

    Should the absent 32.768kHz crystal indeed be the issue, the LF clock in the build must be specified as other than an external crystal otherwise chaos ensues.

    Edit: Also the stand-alone module used to be supplied with Rigado/uBlox firmware, boot stuff, which has to be erased; the development board does not.

Children
Related
Terms of service