Printing counting numbers to Serial randomly adds 10 to the output.

[XanCraft21]

Hello, i have found a bug in the Serial printing functions, if i print a number that counts up one at a time, every so often it will add 10 to that number until it rolls over to the next digit. I tried the normal print function and the one dedicated to integers (i was using Serial1_print and Serial1_print_i) and both do the same thing. If anyone has a solution to fix it i would gladly appreciate that. Thank you for your help.

[DeqingSun]

please add screenshot and simplist code to reproduce the problem.

[XanCraft21]

The first image is of the code i used. The second image is the output from the controller.

[DeqingSun]

Thanks for reporting. Please attach a full window screenshot so I can see your compile configuration.

I'll check next week when I get access to hardware.

[DeqingSun]

The bug can be reproduced with

int counter = 0;
void setup() {
  Serial1_begin (115200);
}
void loop() {
  counter++;
  Serial1_print("LED has flashed ");
  Serial1_print(counter);
  Serial1_println(" times.");
  delay(100);
}

And it happens on Serial0 and Serial1, but not USBSerial. Adding some delay or flush before printing a number can solve the issue. So there should be something wrong in the print buffer handling. I will further investigate it later.

[XanCraft21]

Ok, thank you for looking into this. And sorry i forgot to add the requested full window screenshot, i will add it now. I hope i got the right one.

[DeqingSun]

It seems caused by "3.8.1.4 Common interrupt pitfall: use of non-reentrant functions" described in the SDCC manual.

I will try to add "--int-long-reent" in the compiling process to see if it helps.

[DeqingSun]

The bug can be solved by modifying platform.txt, adding --int-long-reent to compiler.c.flags, and change library link in recipe.c.combine.pattern from lib/small to lib/small-stack-auto (small-stack-auto not packed by the current release, get one from SDCC's build).

I'll do more test and see if this change will cause any additional issue. If not I'll create a commit to fix the bug.

[XanCraft21]

Once again, thank you for looking into this bug. I hope you can get it fixed. For now i will try the previous code fixes you mentioned up above about adding a small delay or serial flush, although to me i think serial flush works faster than the delay, so i will stick with that for the time being.

[DeqingSun]

SDCC's official build still has preprocessor bug that need to be fixed. I thought something like

__asm__("push   __modsint_PARM_2");
__asm__("push   __modsint_PARM_2+1");
uint8_t nextHead = (uart0_rx_buffer_head + 1) % SERIAL0_RX_BUFFER_SIZE;
__asm__("pop    __modsint_PARM_2+1");
__asm__("pop    __modsint_PARM_2");

might also solve the reentrant issue for __modsint . I'll test when I get access to the hardware.

[DeqingSun]

I 've tested the new 0.0.17 release solved this issue. Please try again with new release.

[XanCraft21]

Thank you, i will test it soon.

[XanCraft21]

Sorry, i am not able to test it until the next update it released. I will wait until it comes out.

[DeqingSun]

You can remove the package and add again.

[XanCraft21]

I did not think to do that. I will try it soon. Thank you again.

[XanCraft21]

Once again, thank you for fixing the bug. I tested it and it worked perfectly.