Artemis ATP BLE and RTC issue

[metanav]

Subject of the issue

I just received Artemis ATP board and started using with examples.
The Blink example works.
The BLE_LED and RTC example is not working.

Your workbench

• What platform are you using?
  MacOS

• What version of the device are you using? Is there a firmware version?
  SparkFun RedBoard Artemis ATP. Sparkfun Apollo 3 Boards version 1.0.24.

• How is the device wired to your platform?
  USB C connected to Macbook Pro

• How is everything being powered?
  USB C connected to Macbook Pro

• Are there any additional details that may help us help you?
  I used the same examples with Sparkfun Edge and it is working fine.

Steps to reproduce

I just uploaded default examples using Arduino IDE.

Expected behaviour

1. After uploading BLE_LED example it should appear in nRF connect app as "Artemis BLE".
2. After uploading RTC example the time should be changing every second.

Actual behaviour

1. There is no "Artemis BLE" advertisement label appears in the nRF connect app.
   The serial monitor outputs is as follows:
   Apollo3 Arduino BLE Example. Compiled: 22:10:13
   fm: NusHandlerInit, file: /var/folders/ck/1n_m22xn15zdntmwtj9bvx400000gn/T/arduino_build_927532/sketch/nus_main.c, line: 1073
   fm: NusStart, file: /var/folders/ck/1n_m22xn15zdntmwtj9bvx400000gn/T/arduino_build_927532/sketch/nus_main.c, line: 1161
   fm: tagAttCback, file: /var/folders/ck/1n_m22xn15zdntmwtj9bvx400000gn/T/arduino_build_927532/sketch/nus_main.c, line: 387
   fm: NusHandler, file: /var/folders/ck/1n_m22xn15zdntmwtj9bvx400000gn/T/arduino_build_927532/sketch/nus_main.c, line: 1119
   fm: tagProcMsg, file: /var/folders/ck/1n_m22xn15zdntmpwtj9bvx400000gn/T/arduino_build_927532/sketch/nus_main.c, line: 938
   sg->hdr.event: 0x0052
   [ serial output stops after above line]

2. The RTC example serial output:
   RTC Example
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday
   It is now 22:09:16.00 01/12/20 Day of week: 0 = Sunday

[metanav]

I uploaded and ran many other examples programs including ToggleAllPins. It seems the issue has been resolved automatically. I do not know which example program fixed this but I think ToggleAllPins may have some role. I am not sure.

[nseidle]

I am confused, both BLE and RTC examples are working for you now? That's good news.

[metanav]

Yes both are working fine now.

[nseidle]

Excellent. Thanks for reporting the issue and coming back to let us know it's working. Please don't hesitate to open a new issue if something comes up.

[metanav]

@nseidle It happened again. This morning I uploaded EXAMPLE8_BLE_LED and it appeared in the nRF Connect (iOS App) as "Artemis BLE". I connected to it and tried to send 0x00 and 0x01 which worked 2 or 3 times then it was showing disconnected in the nRF connect and after that it was never appeared in the app scan list ( even after reset or re-uploading).

I checked the RTC example (EXAMPLE1_getTime) and the time was not updating every second. I quickly uploaded ToggleAllPins example and checked again the EXAMPLE8_BLE_LED and EXAMPLE1_getTime one by one and they started working again.

What could be the issue? Is it something related to low power mode? Why RTC also stopped working or MCU was not able to get time from RTC? Why ToggleAllPins fixed the issue? What should I check next time if it happens again? I guess it is not a hardware issue or is it?

[afoxinsocks]

@metanav I discovered a few days ago that the BLE hardware needs some time to come up before you start configuring it. In the BLE example, there is a 1000ms sleep right at the beginning of setup() that accomplishes this, even though it definitely isn't documented as such. This should be fixed in the example.

If the board is already running before the sketch starts, it has no issue configuring the BLE hardware (i.e. if you just programmed it directly from Arduino) without a delay, but if you power it up separately, there will be issues.

I found that about 500ms+ is necessary to delay before initializing BLE.

[metanav]

@afoxinsocks So you mean we should add 1 second delay in the setup()? OK I will try next time when it happens again. If this is the case, BLE and RTC issues are related with the waking up of the Artemis module?

[afoxinsocks]

I'm not sure, really. I know that the delay in the Example on the Nano is necessary on boot for the BT to work properly. May be as well for the RTC. I'd wait to hear from the expert (Nathan) though... I'm just another guy trying to use the Artemis Nano :)

[oclyke]

FYI I have modified the example to have the 1 sec delay in setup by default, as well as to use UART debug statements by default.

[metanav]

@nseidle @oclyke Today nothing is working. I tried all possibilities. Since you are not facing these issues so now I believe it is hardware issue. I bought the Artemis ATP from Mouser. To whom should I ask for replacement, Mouser or directly Sparkfun?

Edit: By the way I bought this board for Hackster.io contest (Machine Learning in the Real World). I am relying on BLE and RTC functionality so it a blocking issue for me.

[nseidle]

If you think it's still a hardware problem please contact Mouser for a return.