Only one 7-segment display working about b3603 HOT 4 OPEN

Hi,

I'm been able to get the display working!
However not in a way i understand, i suspect a compiler issue.

Checked code of display.[ch], and did not find any issue.

While debugging, I discoverd

Changing in function:

void display_refresh(void)

display_word(digit | display_data[i]);

to
display_word(digit | display_data[0]);

Shows all active 4 digits (instead only the last one).
This prooves the display/shiftregister logic itself works.

So there must something wrong with display_data[1..3]
Again checked the code, and all looks good.

While debugging further i came with a workarond which i cannot explain
othere then beeing a compiler issue.

In function:
display_show
pending_display_data[3] = display_char(ch1, dot1);
pending_display_data[2] = display_char(ch2, dot2);
pending_display_data[1] = display_char(ch3, dot3);
pending_display_data[0] = display_char(ch4, dot4);

    if ( pending_display_data[0] == pending_display_data[1] == pending_display_data[2] == pending_display_data[3]) {
    uart_write_str("ERROR\n\r");
    }

pending_update = 1;

Added code basically touching the fresh data,
the uart_write_str("ERROR\n\r)"; isn't actually triggered (checked), but
this workaround makes all digit's working including dot.

Removing the uart_write_str() causes the the single digit issue to be back.
but a __asm__("nop\n"); instead uart_write works just as good (to prevent empty loop optimizations)

I expect this is a compiler issue
$ sdcc -v
SDCC : mcs51/z80/z180/r2k/r3ka/gbz80/tlcs90/ds390/TININative/ds400/hc08/s08/stm8 3.5.0 #9253 (Mar 24 2016) (Linux)
published under GNU General Public License (GPL)

running on "Ubuntu 16.04.3 LTS" (64bit)

note the workarond produces a warning:
$ make
DEP display.c
CC display.c
display.c:107: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int
display.c:107: warning 185: comparison of 'signed char' with 'unsigned char' requires promotion to int
LINK b3603.ihx
Code fits the flash, it is 7863

Anyway, there is a workaround for the single digit issue, suspecting it is
related to sdcc.

Regards,

Arjan

from b3603.

Hi,

looking into the possible compiler issue, I created 3 situations.

1. the non-working situation (bug_* files)
2. the working version (workaround_* files)
3. the non working version code just (display.c) recompiled with --no-peep
   (nopeephole_* files)

to my surprise 3) works as well!!
Definitly pointing to compiler optimazation issues

Added --no-peep to Makefile:
CFLAGS= -lstm8 -mstm8 --opt-code-size --std-c99 --fverbose-asm --no-peep
and recompiled alal the stuff, but onfortunately, the b3603.ihx becomes to
big:
Code is too large, it is 8502 bytes

created a 4th test case, by using the latest build of sdcc and --no-peep
http://sdcc.sourceforge.net/snap.php
With still --no-peep in Makefile results in:
Code is too large, it is 8388 bytes
Smaller that 3.5.0 version I had used before, but stil too large to load.

A 5th case by using the latest build of sdcc without --no-peep
results in:
Code fits the flash, it is 7662
small enough to load, and and display works as expected now!

To my opinion the this open issue may be closed as compiler issue, and sdcc
snapshot of today sdcc-snapshot-amd64-unknown-linux2.5-20171203-10186.tar.bz2
solved it.

While using the latest snapshot I noticed a few warnings :
main.c:451: warning 158: overflow in implicit constant conversion
eeprom.c:43: warning 158: overflow in implicit constant conversion

At the specific lines i did not notice anything special.

Attached the first 3 debug cases for those interested finding out which specific compiler bug was triggered.
Regards

Arjan
b3606_compiler_issue_debug.zip

from b3603.

Confirmed/me too.

from b3603.

Sorry for the late response, I haven't been using my b3603 units much and so don't have an easy setup to test this on and verify. I hope I can get to it sometime soon.

from b3603.