Different value of current current on Buspirate display and TTY

This thread is per request to discuss Buspirate Github issue #16
The firmware is compiled from last week if there was any more recent changes I can try it. But if this behaviour is neither intended nor simply overlooked I assume the easiest answer is some race condition which prevents screen refresh logic to finish as expected

Is the empty function disp_default_cleanup responsible for cleaning it before writing new value ?
Can you present the exact of this display_cleanup concept behind this in different modes ?


typedef struct _display
{
	void (*display_periodic)(void);		// service to regular poll whether a byte has arrived or something interesting has happened
	uint32_t (*display_setup)(void);			// setup UI
	uint32_t (*display_setup_exc)(void);		// real setup
	void (*display_cleanup)(void);			// cleanup for HiZ
	void (*display_settings)(void);		// display settings 

I’m using it in SPI mode and have hard time finding any logic responsible for printing and cleaning the screen

Thank you so much for bringing this to the forum. I’m sorry for the delay, I’ve been out sick for a few days.

The main bits that control the display update are in system_monitor.c which decides which digits need to be updated, and then around line 369 in pirate.c on the second core is where the update takes place. The display mode functions are in the displays array you found, but the cleanup is for reset after ending a mode (such as scope).

I’m still investigating, but my hunch is that there is some concurrency issue still unresolved, maybe with the system monitor. This could explain why it happens to you but I can’t reproduce it.

Does this happen every time you go above 100ma? the 1 is sticky? T here’s no blown fuse (current limit set) or anything like that? Does it clear if you disable/enable to PSU with the w/W command?

Hi, just wanted to follow up on this one because it’s a weird corner case. Can I send you a new board and possibly have you mail me that one?

Hello
I will let you know as soon I will have something on bench . The board I was testing was RTL8710 with SPI flash. I was connecting buspirate to the SPI flash in packages I don’t know exactly but it was smaller than my 5x6 WSON adapter I was connecting to it up with microhooks(not from Buspirate sets) and it took mi 40min so not the easy one to reproduce. Will try some other circuits and will let you know. Can you help understand high level architecture with this display logic/multicore and exact concurency issue? Are there any critical sections defined or it “just works” . In case of exact mode I’m using - SPI how this is exactly handled?
As just looking at the logic:

if(lcd_update_request){
...
}

I can imagine some TOCTOU scenarios e.g when there are two subsequent trigers for setting and clearing lcd_update_request. Also try ChatGPT prompt:
Identify TOCTOU issue with lcd_update_request in below code: <whole pirate.c code here> it says something about LCD irqs, pointing lcd_irq_enable didn’t go through it yet as I would need to undertstand whole code first

As much as possible, it’s a cooperative multitasking loop on both cores, but especially the second core that does LCD, USB, LEDs, analog monitoring , etc is never blocking.

Where we have possible contention rp2040 has an atomic bit they call spinlock. The firmware has spinlocks on the USB IO FIFO queue, shared SPI onboard controller, and now the ADC.

An interrupt every 0.5s sets a flag to update the toolbar and display. The second core loop checks what is eligible to be updated and sets some flags. The system monitor then goes through the update flags, checks what new digits are different than previous readings (3.3v vs 3.2v), then updates only those in the toolbar and LCD (_3) to minimize API traffic and VT100 refresh bandwidth.