Serial monitor not working (but uploading ok) - Core 1.0.6 issue?

SPARK-X
1

Hi,

I upgraded to Core 1.0.6, hoping to fix other problems but have created a new one, serial output doesn’t work any more. This issue is persistent even when I burn the bootloader, and revert back to earlier cores.

  1. Could upload code ok and then monitor serial on core 1.0.2

  2. Upgraded to core 1.0.6 and changed some code and now serial doesn’t work (inc. TX LED doesn’t flicker). When I uploaded my previous test code, serial still doesn’t work, so either the core has corrupted something, or my code has. I may have done a bad thing while being lazy with passing a string instead of a pointer and hoping it would work:

  displayInput("Switch",switchPin, "", isDigital);
}

void displayInput(char* inputName, int inputPin, char* inputUnit, bool inputType)
{
  Serial.print(inputName);
  Serial.print(":");
  if(inputType == isDigital)
    Serial.print(digitalRead(inputPin));

  1. Downgraded to core 1.0.5, can upload, but serial doesn’t work. Tried uploading bootloader, and no difference.

  2. Downgraded to core 1.0.4, same as 1.0.5 (except I tried restarting the IDE this time)

  3. Downgraded to core 1.0.2 (1.0.3 not available). “No announcement from bootloader” error when trying to upload code, so presumably a different bootloader. Tried “burn bootloader”, but as expected, didn’t work. Used the old example sketch method to burn the older bootloader (successfully, by messages and RX/TX activity), then still getting the same “No announcement” error when I try to upload my test code.

  4. Other test board which didn’t have exposure to new code or core 1.0.6 accepts upload, and serial works fine.

I’m out of ideas until my JTAG programmer arrives. Can anyone confirm the 1.0.6 core serial comms are working for them? (I don’t want to risk bricking the only working board I have left)

Cheers,

Steve

2

HI Steve - I noticed a similar issue when using the Ambiq Secure Bootloader on v1.0.6. My issue as accurately as I can describe it is this:

When uploading with Ambiq Secure Bootloader with the Arduino serial monitor window open the board gets hung up (somewhere). If the serial monitor window is closed, however, the code appears to execute without trouble. (https://github.com/sparkfun/Arduino_Apollo3/issues/46)

How does that align with your experience? There have been a lot of changes to bootloaders between 1.0.2 and 1.0.6.

I have not encountered this issue when using the SparkFun Variable Loader. Have you upgraded the SVL on your board by following this post? viewtopic.php?f=163&t=50480&p=206258&hi … er#p206258

We are going to remove the ASB option in the next release of Arduino because it is not designed specifically for use within Arduino. However it will still be available on the boards (for advanced users) and it will be used for the ‘Burn Bootloader’ step.

3

Hi LS,

I’ve had to work on other things for a while, but revisiting this. Your issue doesn’t appear to have much in common. It’s not an issue with the serial window being open, or the Artemis hanging. It’s just the serial comms don’t work. The hardware is fine because code can be uploaded.

I figured out that the issue is related to the Tools → Board setting. If set to “Artemis Module”, the serial comms don’t work. If set to any other Artemis, the comms work just fine. I’m running the SerialCallResponseASCII example with pin-specific reads commented out, and this is illustrates it well. Same thing happened on my custom board using the Artemis Module and on a BlackBoard (Uno footprint) from Sparkfun.

Checking on the core… it’s a bug!

For the “Artemis Module” Arduino_Apollo3/variants/SparkFun_Artemis/config/variant.cpp… there is

Uart Serial(0, 23, 22); // Declares a Uart object called Serial using instance 0 of Apollo3 UART peripherals with RX on variant pin 23 and TX on pin 24 (note, you specify *pins* not Apollo3 pads. This uses the variant's pin map to determine the Apollo3 pad)

That code is from the Artemis Blackboard, corresponding to Apollo pads 49, 48 for RX and TX respectively via the Blackboard pad mapping, but being incorrect for the directly mapped Module pads.

The correct code for the Artemis module would be

Uart Serial(0, 49, 48);
``` (and this is reflected in the Artemis ATP variant.cpp)

Until the core can be updated, the workaround is to select "Artemis ATP" as your board, rather than "Artemis Module". It has the correct code for Serial0 and all the others are are directly mapped so are correct too.
4

Aha! Nice catch. I’ve fixed that bug here: https://github.com/sparkfun/Arduino_Apo … 7525aa8e31

It won’t be generally available until the next release of the core, however.