NRF52 compability?

[victorpasse]

Is there any intentions to port the mesh to NRF52? What would be the required changes to support NRF52?

[daviddedwin]

We will have an basic version of the port available, optimistically next week, but it will take time for it to get all the features that the nRF51 has like DFU etc.

[daviddedwin]

A basic nRF52 Port is available in the nRF52_Port branch of the repo. This does not support DFU and only supports the BLE gateway example. The support for DFU is not likely to be added quickly so expect some long waits.

[victorpasse]

Good, I will try this mesh out in some time.

[AlexDM0]

Hi,

What is the current status of the NRF52 compatibility? The master branch is many many commits ahead of the port branch. Is there any work on this?

Cheers

[trond-snekvik]

Hi,

We've devoted resources to the nRF52 port, and some work is being done internally to bring it up to date with the master branch. We want to add nRF52 support for the bootloader as well, and hope to push an update to public sometime this fall.

[AlexDM0]

Hi Trond,

Thanks for the update! Is it not functional at all on the 52 at the moment? We're updating our firmware to run on the 52 right now.

Regards

[trond-snekvik]

It's designed to be easily portable, but we haven't tested it on 52 at all, and expect some trouble.

I believe the worst obstacle is the increased page size, and the timing/resource usage spike that causes. There's also some trivial mistakes lying around, like hardcoded defines and similar stupidity, that could cause you some trouble.

Post issues for the problems you can't find solutions to, and I'll do my best to help you out :)

[mrquincle]

@trond-snekvik I run into trouble when calling timer_get_timestamp, see https://github.com/crownstone/bluenet/issues/26. It's a hardfault, so I've not much more information.

Edit: never mind, I see that in your newer code that function doesn't even exist.

[mrquincle]

Okay, I've an nrf52 port that SDK-11 compatible at https://github.com/mrquincle/nRF51-ble-bcast-mesh/tree/nrf52.

#0  HardFault_HandlerC (hardfault_args=<optimized out>) at /home/anne/workspace/bluenet/src/util/cs_Error.cpp:73
#1  <signal handler called>
Read 4 bytes @ address 0x2000FD90 (Data = 0x2000FDB0)
#2  0x000267ba in sd_ble_gap_address_get (p_addr=p_addr@entry=0x2000fdb0) at /home/alex/Nordic/SDKs/v11.0/components/softdevice/s132/headers/ble_gap.h:1045
Read 4 bytes @ address 0x2000FDB8 (Data = 0x20003A7E)
Read 4 bytes @ address 0x2000FDB8 (Data = 0x20003A7E)
#3  0x000268aa in mesh_packet_set_local_addr (p_packet=p_packet@entry=0x20003a7e <g_packet_pool>)
    at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/mesh_packet.c:147
Read 4 bytes @ address 0x2000FDB8 (Data = 0x20003A7E)
Read 4 bytes @ address 0x2000FDC8 (Data = 0x00000001)
Read 4 bytes @ address 0x2000FDC8 (Data = 0x00000001)
Read 4 bytes @ address 0x2000FDC0 (Data = 0x00000000)
Read 4 bytes @ address 0x2000FDC0 (Data = 0x00000000)
Read 4 bytes @ address 0x2000FDC0 (Data = 0x00000000)
Read 4 bytes @ address 0x2000FDC0 (Data = 0x00000000)
Read 1 bytes @ address 0x2000FDD8 (Data = 0x00)
#4  0x000268e8 in mesh_packet_build (p_packet=0x20003a7e <g_packet_pool>, handle=handle@entry=1, version=version@entry=0, data=data@entry=0x0, 
    length=length@entry=0 '\000') at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/mesh_packet.c:181
#5  0x00028830 in handle_storage_flag_set (handle=<optimized out>, flag=<optimized out>, value=<optimized out>)
    at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/handle_storage.c:491
#6  0x0002611a in async_event_execute (p_evt=0x2000fe04) at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/event_handler.c:76
#7  event_fifo_pop (evt_fifo=evt_fifo@entry=0x2000398c <g_async_evt_fifo>) at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/event_handler.c:97
#8  0x0002615c in QDEC_IRQHandler () at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/event_handler.c:114
#9  0xffffffe8 in ?? ()

There's not much special about sd_ble_gap_address_get. I'm calling it before. Perhaps it's because it's in the QDEC_IRQHandler?

[trond-snekvik]

You seem to be getting a hardfault on an SVC call. Since the number of IRQ levels are higher on the nRF52, the Softdevice SVC level has been moved to a lower priority, level number 4. The event handler (from your QDEC at frame 8) sets the event IRQ to level 3, which makes it above the SVC in priority. Calling an SVC function from a higher priority context results in a hardfault.

Try moving the event handler level to one of the levels marked blue above the main (level 6 or 7), and you should get rid of it. Did you resolve the timestamp issue?

[mrquincle]

@trond-snekvik Cool. I've set it to 6 and it gets rid of it indeed. I now see you have done this already in the nRF52 branch, but it is difficult for me to see the differences with main. I'm running into something else now, but I'll debug it myself first a bit more.

[mrquincle]

@trond-snekvik It might be better to ask for your help. :-)

#0  app_error_handler_bare (error_code=<optimized out>) at /home/anne/workspace/bluenet/src/util/cs_BleError.cpp:43
#1  0x0002715e in timer_event_handler () at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/timer.c:102
#2  0x000276c4 in radio_signal_callback (sig=<optimized out>) at /home/anne/workspace/nRF51-ble-bcast-mesh/nRF51/rbc_mesh/src/timeslot.c:297
#3  0x0001ab86 in ?? ()

What are the conditions under which APP_ERROR_CHECK_BOOL(m_active_callbacks & (1 << i)); fails?

[trond-snekvik]

This appears to be a hardware-software race condition that's hidden on the 51. There shouldn't be any side effects to change the assert into an if, protecting lines 104 to 124. To get rid of the real race codition though, you should make sure that the callback and the callback field is set before enabling the timer IRQs (with timer_set()), and also clear any pending NRF_TIMER0->EVENTS_COMPARE[i] flag after the timer_abort() hardware reset on line 253.

Make sure that the flag is never set when the callback function pointer is invalid, and that the flag is set as long as the IRQ is enabled, and you should get rid of the assert completely.

[mrquincle]

@trond-snekvik Thanks a lot! I did already did the workaround by changing it into an if and for now it seems to be plowing forwards without any trouble. Let's see how it behaves under pressure. :-)