On the Hunt for a Serial Problem

PicoCalc
1

We have a serial port problem in PicoMite. The PicoCalc can receive but not send through the onboard serial port (not the one on the Pico itself)

Here’s a hint for you if you’re going looking for it:
The problem doesn’t occur in WebMite, only the non-web version. Webmite’s serial response is just what it should be. This is a clue to the hunt for the serial bug. If you have any knowledge of C at all, Please help us find the bug! The more eyes on it, the faster it can be found.

1 Like
2

Hold your horses, I think I may have found the problem but I need a little bit of time to confirm.

1 Like
3

The analysis of this has taken many days/hours to understand the problem, getting into the problem with two debug (uart) probes on the UART0 and UART1, with dbg tracing the flow in the program, seeing the data go into the uart0 with evidence that the data was removed from uart0 but no output on pin1 as shown on my oscilloscope. While taking a walk I came to the conclusion that something is blocking the data on pin 1 but no idea where to start looking.

The problem is only shown on a PicoCalc using a Pico2, all other versions do not have this problem. The plain PicoMite (not PicoCalc) build has only a few options installed, so I removed all the options from the PicoCalc build and found that the following option causes the problem to appear:

OPTION LCDPANEL ST7796SP, PORTRAIT,GP14,GP15,GP13,,INVERT

The above information is created from the options as shown in FileIO.c:

    Option.DISPLAY_TYPE = ST7796SP;
    Option.SYSTEM_CLK = 14;
    Option.SYSTEM_MOSI = 15;
    Option.SYSTEM_MISO = 16;
    Option.DISPLAY_BL = 0; //stm32 control the backlight
    Option.LCD_CD = 19;
    Option.LCD_CS = 17;
    Option.LCD_Reset = 20;
    Option.DISPLAY_ORIENTATION = PORTRAIT;

With the visual inspection of the code I found the following in SPI-LCD.c that is used for PICOMITERP2350 only:

#if PICOMITERP2350
		if (Option.SYSTEM_CLK != Option.LCD_CLK)
		{ // configure the LCD SPI pins
			gpio_set_function(LCD_CLK_PIN, GPIO_FUNC_SPI);
			gpio_set_function(LCD_MOSI_PIN, GPIO_FUNC_SPI);
			gpio_set_function(LCD_MISO_PIN, GPIO_FUNC_SPI);
			gpio_set_drive_strength(LCD_MOSI_PIN, GPIO_DRIVE_STRENGTH_8MA);
			gpio_set_drive_strength(LCD_CLK_PIN, GPIO_DRIVE_STRENGTH_8MA);
			gpio_set_input_hysteresis_enabled(LCD_MISO_PIN, true);

When you look at the options in FileIO.c you can notice that Option.LCD_CLK is not included, iow this option is 0 (zero) and not equal to Option.SYSTEM_CLK. Please note that I mentioned Pin 1 above which GP0 (or the value zero). What happens next is killing the output on pin 1 = GP0 because value of Option.LCD_CLK_PIN is zero!

gpio_set_function(LCD_CLK_PIN, GPIO_FUNC_SPI);
.
.
gpio_set_drive_strength(LCD_CLK_PIN, GPIO_DRIVE_STRENGTH_8MA);

Please note that I do not know why this routine exists and I did not investigate further.

There are two solutions to this problem, the first solution would be to do additional checking in SPI-LCD.

#if PICOMITERP2350
		if ((Option.SYSTEM_CLK != Option.LCD_CLK)) && (Option.LCD_CLK != 0))

but this would require a change in the MMBasic.

The simpler solution is to add Option.LCD_CLK to the PicoCalc initial options in FileIO.c:

    Option.DISPLAY_TYPE = ST7796SP;
    Option.SYSTEM_CLK = 14;
    Option.SYSTEM_MOSI = 15;
    Option.SYSTEM_MISO = 16;
    Option.DISPLAY_BL = 0; //stm32 control the backlight
    Option.LCD_CLK = 14;
    Option.LCD_CD = 19;
    Option.LCD_CS = 17;
    Option.LCD_Reset = 20;
    Option.DISPLAY_ORIENTATION = PORTRAIT;

After the above change the UART0 was able to transmit data :wink:

I am preparing a large number of changes to the code for the PicoCalc and this will be included.

5 Likes
4

Looking at the definition of the option structure in FileIO.h it appears it is arranged to be a packed structure that fits in 7 128 byte blocks. The added picocalc option

#ifdef PICOCALC
uint8_t KEYBOARDBL;
#endif

does not take the packing into account, potentially leaving the next (u)int16_t unaligned and will also cause the option structure to exceed the 896 bytes. I don’t know if this will cause problems but it doesn’t feel right.

5

I have already noted this and fixed in my changes. Also I removed the purpose of this byte and replaced it with a new function to manage/track the LCD and KBD backlight.

6

Small update, the Option.LCD_CLK is only used with PICOMITERP2350, for this reason an #if should be included:

#if PICOMITERP2350
    Option.LCD_CLK = 14;
#endif
7

Code like that also appears in MM-Misc.c. Does the change have to be made there as well?

Tom L

8

Yes, it has been done already.

1 Like