Advantest/ADCMT R6581 VFD to TFT conversion

[IanJ]

Hi all,

I have moved my implementation of the VFD replacement on the R6581 to here as I felt it was getting a bit heavy for MickleT's original thread (see below).....my intention was not to take over his thread, but it was starting to head that way!
MickleT's Advantest R6581 VFD replacement thread:
https://www.eevblog.com/forum/repair/advantest-r6581-vfd-replacement/

The background to my TFT conversion you can find here:
https://www.eevblog.com/forum/repair/advantest-r6581-vfd-replacement/msg5732473/#msg5732473
https://www.eevblog.com/forum/repair/advantest-r6581-vfd-replacement/msg5743707/#msg5743707

In this thread I'm further documenting the mods and new functionality I am adding to my TFT conversion.

Again, my project could not have been done without the great work by MickleT. He not only reversed engineered much of the R6581 DMM but then came up with a great OLED conversion for failing VFD's.

##################################################################

Video:
Published on my TFT LCD effort (based on my original software/hardware):
https://youtu.be/rv6x6VsWyRo

Files:
These will be updated:

• GIT source = https://github.com/Ian-Johnston/R6581_VS_Display
• GIT .HEX file 26/01/25, see hex file attached to this post.
• Gerbers 24/01/25 V1.3, see zip file attached to this post.
• Optional Display LCD holder, see zip file attached to this post.

Note: V1.1 & V1.2 gerbers have a short circuit on them (easily cleared), Click on thumbnail image below for photo of the Pcb, cut the tracks as identified by the 3 red 'X'.


Instructions:
Revised instructions 06/03/25.
Important: The latest firmware requires the DCV switch is hooked up, otherwise you may get a blank display.
See 2off PDF files attached to this post - Instructions_V2.pdf & TimingAdj.pdf.

Parts:
LCD & LT7680A-R (c/w flat flex & FPC conn) = https://www.buydisplay.com/bar-type-4-58-inch-320x960-ips-tft-lcd-display-spi-rgb-interface
The LCD (on it's own) is also available here = https://www.adafruit.com/product/5805
1 x 33uF 100V electrolytic capacitor (optional)
1 x 100uF 10V electrolytic capacitor
1 x 1uF polyester capacitor
2 x 10mm M3 brass standoffs
1 x STM32 Blue Pill (STM32F103C8T6) - 64k version. BEWARE some cheap Chinese versions are 32k flash apparently. Flash req'd = 37KB out of 64KB (58%), SRAM req'd =3688 bytes out of 20KB (18%)
1 x 5-way male SIL header
2 x 20-way arduino style female header
2 x Strips 2mm double sided tape
1 x Strip 6mm single sided foam

1 x Optional - LCD holder 3D .STL files for easier LCD mounting (no tape or foam required):
     See zip file attached to this post, courtesy vf33184 (Vladimir).

Screenshots:
Before (not my actual unit, mine was worse!):


After (with splash screen showing):


Disclaimer:
This work is experimental. Whilst I offer friendly support, you are on your own in terms of responsibility if things go wrong for you, or you don't like the result. You have been warned.

Ian.

[IanJ]

MOVED FROM HERE:
https://www.eevblog.com/forum/repair/advantest-r6581-vfd-replacement/msg5776769/#msg5776769

Hi all,

I have made some mods to my TFT implementation of the display.

MOD. 1 - 9th Jan '25
I have always wanted a 1 VDC range for the R6581. Now, we do get a 1000 mV range however I guess I am too used to my 3458A where it will display X.XXXXXXX VDC.
So, I added a new mode whereby if you are on the 1000mV Range and you hit the DCV button it will switch the display out to a new 1 V Range.
It gets its data from the 1000 mV Range and so you get an extra digit, one more than the 10 V Range for instance at max 8.5 digits.
See photo below.

The Blue Pill uses two additional inputs to interface to the DCV button, see photo below.
Two are required because the button is multiplexed and I need two inputs to somewhat read a button press.

GIT source = https://github.com/Ian-Johnston/R6581_VS_Display
GIT .HEX file = https://github.com/Ian-Johnston/R6581_VS_Display/tree/master/VisualGDB/Debug

Only upgrade to this version is you hook up the new inputs to the DCV switch.

New Pcb gerbers attached which include the new A11/A12 connections.

Any issues then let me know (there are a couple of very small things).

PS. For the coders, The Blue Pill doesn't have a hardware FP and the software FP was being a pain, i.e. I wanted to use atof but it just continued to return empty, so I wrote around it (ugghh!). There doesn't seem to be any downsides though. I’ll return to this soon as atof is a lot less code.

UPDATE - 9th Jan '25
Digital input A11/A12 logic tweaked.

UPDATE - 10th Jan '25
1 VDC mode is now quite a bit more seemless, once it is set then it will remain in 1 VDC mode even if overrange or the DMM is in AUTO mode.
GIT hex file updated.
Still to do: try to reverse engineer the keypad better to fully isolate that button.

UPDATE - 15th Jan '25
Vertical Back Porch for TFT set to 11 rather than 10 (10 is per spec!) due to TFT flickering issue when running the R6581T for 20hrs.
Possibly the a heat/stability issue with the LT7680A-R or the TFT itself. They do run pretty warm in there (I might look at a fan upgrade)!

UPDATE - 16th Jan '25
Horizontal Back Porch for TFT set to 30 rather than 20 (20 is per spec!) due to TFT still flickering issue when running the R6581T for 12hrs.
I have attached the original HEX file and this new one.

UPDATE - 19th Jan '25
Fix issue where random pixels might appear at right hand vertical edge.
See new HEX file.

UPDATE - 20th Jan '25
Display still flickering at times, found that TFT timings was incorrect, the TFT is 400x960 but with partial glass, i.e. -80. So, must be treated as 400x960 in software.
See new HEX file.

UPDATE - 23rd/24th Jan '25
Still chasing the flickering problem which seems to return randomly, or temperature related.
Porch and start timings - LCD_VBPD, LCD_VFPD, LCD_VSPW, LCD_HBPD, LCD_HFPD, LCD_HSPW
1 -  17, 15, 1, 50, 30, 10         Haven't tested fully
2 -  17, 15, 2, 50, 30, 10         Stable with freezer spray & heat gun, single vertical line at right
3 -  17, 15, 3, 50, 30, 10         Flickers when cold, no vertical line
4 -  17, 15, 4, 50, 30, 10         Flickers badly
5 -  17, 14, 1, 50, 30, 10         Flickers badly
6 -  17, 14, 2, 50, 30, 10         Stable with freezer and heat gun, has a single vertical line
7 -  17, 14, 3, 50, 30, 10         Stable with freezer and heat gun, has a single vertical line
8 -  17, 14, 4, 50, 30, 10         Stable (except once on startup) with freezer and heat gun, no vertical line - ORIGINAL
Option 6 seems to be the closest to the AdaFruit example but has a vertical line down the right hand side which I can't get rid of. It's the most stable.
Well, I can by adjusting other parameters but it makes the TFT unstable (flickers).
Wierdly, my other R6581T, and ADCMT unit, has no flicker or pixel issues at all.
5 HEX files below to choose from:
R6581_VS_Display_17_14_2_50_30_10.hex
R6581_VS_Display_17_14_3_50_30_10.hex
R6581_VS_Display_17_14_4_50_30_10.hex
R6581_VS_Display_17_14_2_50_30_10_45Hzrefresh
R6581_VS_Display_17_15_2_50_30_10_45Hzrefresh
Gerbers updated to V1.3 due to short across 3 tracks on the Pcb.

See further posts in this thread for more updates.


MOD. 2 - 10th Jan '25
When the LCD shows "DISPLAY OFF" i.e. when the user actions this via the menu, it now turns off the LCD completely (blank). Pressing the MENU button revives.
It reduces the backlight to minimum, and turns off the LCD via register 0x12 of the LT7680.
A user asked for this and I guess it's good for TFT long term saving especially for those running the DMM 24/7.

UPDATE - 12th Jan '25
Bug fix on the backlighting brightness control when implementing DISPLAY OFF.

See further posts in this thread for more updates.

Ian.

[IanJ]

UPDATE - 25th Jan '25
New version in Post #1 available for download (see link to my GIT).

With the issue some folks have been experiencing with flickering on the TFT and the various HEX files I had produced to give users a choice to see which one was most stable for them I decided to bring them all together in one HEX file and give the user the ability to select at R6581 boot.

See Post #1 for the link to my GIT for the latest HEX file, or the download.

This functionality requires the DCV button mod to my Pcb (two small wires soldered between the BluePill and the R6581 DMM board. See previous post.

Hold the DCV button in whilst powering up the R6581 and you should get the following on the LCD.
Alternatively, hold DCV and hit the reset button on the Blue Pill.



The current loaded TFT timing will be displayed, and from there you can press the DCV button to scroll around 6 (currently) loaded TFT timing configurations.
When you see the one you want simply reset power to the R6581.
The new config is saved to Flash (EEprom emulation).

On normal boot the LCD will display as part of the splash screen the currently loaded configuration.


The currently available configs:
VBPD VFPD VSPW HBPD HFPD HSPW Refresh Rate COG (Adafruit/BuyDisplay)
--------------------------------------------------------------------------------------
17     14     2       50      30     10      60                AdaF
17     14     3       50      30     10      60                AdaF
17     14     4       50      30     10      60                AdaF
17     15     2       50      30     10      60                AdaF
17     15     2       50      30     10      45                AdaF
10     12     3       80      30     20      60                BuyD

Most of the above settings effect the LT7680A-R TFT driver IC, the last one is to select either Adafruits or BuyDisplays config data for the ST7701S COG IC.

Note 1:
Holding DCV on boot doesn't always work, you may need to retry up to 10 times before it will 'catch' (I will try to fix this if I can).

Note 2:
I'd like to have the ability to select individual settings for each parameter, but there's only so much I can do on a single DCV button.

Info:
Why is it so hard to get TFT LCD Porch timings and screen coverage correct?
Getting TFT LCD porch timings right is tricky because it requires balancing the physical panel's requirements, the controller's limitations, and the interdependence of resolution, refresh rate, and pixel clock.
Not to mention cheap TFT LCDs from China, lack of good manufacturers tech info and in this case I think these ones or the LT7680A-R may be slightly sensitive to temperature etc.

Ian.

[jj131415]

hi Ian,
I extended the temperature range and tested different FW for your reference:
1) 17_14_2_50_30_10_45Hz ---OK @ 12C~55C, with vertical line
2) 17_14_2_50_30_10_60Hz ---OK @ 12C~55C, with vertical line, I'm using this version now.
3) 17_14_3_50_30_10_60Hz ---OK @ 12C/55C, flickering around 30C, with vertical line
4) 17_14_4_50_30_10_60Hz ---OK @ 20~55C, flickering @ 12C, no vertical line
5) 17_15_2_50_30_10_45Hz ---OK @ 20~55C, flickering @ 12C, no vertical line

Thanks.

[IanJ]

hi Ian,
I extended the temperature range and tested different FW for your reference:
1) 17_14_2_50_30_10_45Hz ---OK @ 12C~55C, with vertical line
2) 17_14_2_50_30_10_60Hz ---OK @ 12C~55C, with vertical line, I'm using this version now.
3) 17_14_3_50_30_10_60Hz ---OK @ 12C/55C, flickering around 30C, with vertical line
4) 17_14_4_50_30_10_60Hz ---OK @ 20~55C, flickering @ 12C, no vertical line
5) 17_15_2_50_30_10_45Hz ---OK @ 20~55C, flickering @ 12C, no vertical line

Thanks.

Thanks, thats good info.

Using my new code, i'm currently switching between two profiles, the one from my pic above - 10, 12, 3, 80, 30, 20, 60, BuyD and the one you are on.

It's wierd, because my other R6581T (ADCMT branded) has never, ever flickered and is rock stable at all temperatures.

Ian.

[IanJ]

UPDATE - 26th Jan '25
New version in Post #1 available for download (see link to my GIT or directly download the new HEX file).

Power up with DCV button pressed to enter TFT Timing Adjust screen now much more reliable.

Ian.

[jj131415]

Hi Ian,
I have another R6581T, it's more new if compare with my R6581D. I will try it later.

Thanks.

[vf33184]

Hello,
I wanted to have better solution to hold new display in place so here is my design of LCD holder. It works well for me and was successfully tested also by Ian.
It can be easily 3D printed. There are 3 versions of STL file, details are described in ZIP file.


Vladimir

[IanJ]

Hello,
I wanted to have better solution to hold new display in place so here is my design of LCD holder. It works well for me and was successfully tested also by Ian.
It can be easily 3D printed. There are 3 versions of STL file, details are described in ZIP file.

Confirmed, no need for double sided tape any more. LCD is easier to fit, secure in place and the important 42mm LCD horizontal position is adhered to.

Much thanks.

Ian

[vf33184]

I have been testing actual firmware version 25-01-26. All six display settings are causing flickering in my case. None has vertical white line issue but I have to note that during assembly I have painted white frame of display by permanent black pen what can be hiding this vertical line that was mentioned by jj131415 for some configurations.

Test setup: R6581T with FW A01, room temperature 22C, meter without enclosure, duration 24h (the behavior was not changing during this period)

I have also made couple of capturing videos. Very common is that at the moment of flicker many symbols on the display are replaced by ? symbol. Not sure if this can help with troubleshooting under what condition display shows ? instead of proper symbol e.g. digit. Most of these flickers are happening on digits, some on yellow text below digits and very seldom is flickering of green text above digits. Probably there is some relation with refresh rate of these symbols?

Also noticed that when I change setting from 1000mV to 1V, after power cycle it returns back to default 1000mV. I would rather prefer to remember last state before power cycle or even better have an option to change this setting permanently in boot menu. But I can live with this behavior for now because flickering issue is most important and we should focus in that one first.

Vladimir

[coromonadalix]

can a test / specially crafted FW could test the refresh rate of the display    or use the same  dmm characters placement indicators layout to see where it could be slower or have some bad timing ??

could it be the bluepill mcu  having a hard time to keep up ?

[IanJ]

I have been testing actual firmware version 25-01-26. All six display settings are causing flickering in my case. None has vertical white line issue but I have to note that during assembly I have painted white frame of display by permanent black pen what can be hiding this vertical line that was mentioned by jj131415 for some configurations.

Test setup: R6581T with FW A01, room temperature 22C, meter without enclosure, duration 24h (the behavior was not changing during this period)

I have also made couple of capturing videos. Very common is that at the moment of flicker many symbols on the display are replaced by ? symbol. Not sure if this can help with troubleshooting under what condition display shows ? instead of proper symbol e.g. digit. Most of these flickers are happening on digits, some on yellow text below digits and very seldom is flickering of green text above digits. Probably there is some relation with refresh rate of these symbols?

Also noticed that when I change setting from 1000mV to 1V, after power cycle it returns back to default 1000mV. I would rather prefer to remember last state before power cycle or even better have an option to change this setting permanently in boot menu. But I can live with this behavior for now because flickering issue is most important and we should focus in that one first.

Vladimir

Interesting!
If you see ?? then it's either characters I haven't converted, or it's data corruption. In this case it's clearly data corruption. So I guess the incoming SPI data is somehow being corrupted.
I notice from your screenshot you are running GPIB at the time......I've tried hammering GPIB and see no issue here.
I notice also you have the INFO annunciator lit......whats that for?......I thought it was "unused" per the Japanese user manual.

On my units I never get ?? at the same moment as flickering, for me it's two different issues. Kind of leads me in this case to power supply dropping out on the LCD or BluePill. Might be worth adding further caps across teh +5VDC & +3.3VDC on my board.

I have just recently got saving to flash working so yes, I can make the 1VDC/1000mV modes more permanent for the user. I'll get to that soon.
*IDN? gives me ADVANTEST,R6581T,0,A01......not sure about my ADCMT branded unit.
With both, I get no flickering.......but like I have said it can appear for no reason, but mostly temperature issues.

I have emailed my contact at Levetop the manufacturers of the LT7680A-R TFT controller IC to see what they make about the flickering. Hoping they can experiment with one! They are normally very helpful to me so we'll see what happens.
Hoping they can give me some definitive settings for the LT7680A-R and also the S7701.

Ian.

[IanJ]

can a test / specially crafted FW could test the refresh rate of the display    or use the same  dmm characters placement indicators layout to see where it could be slower or have some bad timing ??

could it be the bluepill mcu  having a hard time to keep up ?

Possible, but you can see flickering even when pressing the MENU button and displaying static text.
Also, the Blue Pill just sends relatively slow SPI data to the LT7680A-R, and it takes care of writing to the TFT......so even if the SPI stops then the TFT will just remain with the last data on it.

TFT flickering is a known phenomenon. The frequencies involved (between LT7680A-R IC and the TFT) are up at 60MHz......and akin to controlling an old CRT in some respects.

Saying that, i'll create a version of firmware for SPI & TFT testing. Check back soon.

R6581_VS_Display_Test2.hex
The attached TEST hex file runs the TFT refresh rate slower, 100ms instead of 35ms.
On the MAIN display it will count each time the TFT is updated.
On the AUX display it will count each time data is captured from the R6581 SPI bus.

R6581_VS_DisplayTestTFTonly1.hex
TFT counter only, VFD SPI is disabled.

UPDATE:
See new HEX file, any VFD SPI error codes are now reported.

I'll add more 'tests' when I can in order to detect errors/corruption, but for now it's running the TFT refresh rate slower, that's about it so let me know.

Ian.

[vf33184]

Interesting!
If you see ?? then it's either characters I haven't converted, or it's data corruption. In this case it's clearly data corruption. So I guess the incoming SPI data is somehow being corrupted.
I notice from your screenshot you are running GPIB at the time......I've tried hammering GPIB and see no issue here.
I notice also you have the INFO annunciator lit......whats that for?......I thought it was "unused" per the Japanese user manual.

On my units I never get ?? at the same moment as flickering, for me it's two different issues. Kind of leads me in this case to power supply dropping out on the LCD or BluePill. Might be worth adding further caps across teh +5VDC & +3.3VDC on my board.

I have just recently got saving to flash working so yes, I can make the 1VDC/1000mV modes more permanent for the user. I'll get to that soon.
*IDN? gives me ADVANTEST,R6581T,0,A01......not sure about my ADCMT branded unit.
With both, I get no flickering.......but like I have said it can appear for no reason, but mostly temperature issues.

I have emailed my contact at Levetop the manufacturers of the LT7680A-R TFT controller IC to see what they make about the flickering. Hoping they can experiment with one! They are normally very helpful to me so we'll see what happens.
Hoping they can give me some definitive settings for the LT7680A-R and also the S7701.

Ian.

Hi Ian,
those symbols TLK, LTN and INFO from my picture are ghosts during flicker only, in a normal situation I have only AZERO and FRONT lit plus SMPL blinking. I have not been using GPIB yet except short test that it works, got ADVANTEST,R6581T,0,A01 response to *IDN? so the same as your.  I am just curious how come that e.g. INFO is lit during flicker stage when you never call it via SPI to be lit?

Regarding power supplies, I have measured power consumption of whole display including Blue Pill an it is just 1.1W so I doubt it can overload meter power supply if whole meter has 30W.  I will try to setup monitoring of incoming 5V to your board to see if there are any glitches.

UPDATE: I have been measuring 5V input to your board, there is less than 1mV fluctuation in voltage so I don't think there is an issue with power supply quality/stability.


Vladimir

[IanJ]

Interesting!
If you see ?? then it's either characters I haven't converted, or it's data corruption. In this case it's clearly data corruption. So I guess the incoming SPI data is somehow being corrupted.
I notice from your screenshot you are running GPIB at the time......I've tried hammering GPIB and see no issue here.
I notice also you have the INFO annunciator lit......whats that for?......I thought it was "unused" per the Japanese user manual.

On my units I never get ?? at the same moment as flickering, for me it's two different issues. Kind of leads me in this case to power supply dropping out on the LCD or BluePill. Might be worth adding further caps across teh +5VDC & +3.3VDC on my board.

I have just recently got saving to flash working so yes, I can make the 1VDC/1000mV modes more permanent for the user. I'll get to that soon.
*IDN? gives me ADVANTEST,R6581T,0,A01......not sure about my ADCMT branded unit.
With both, I get no flickering.......but like I have said it can appear for no reason, but mostly temperature issues.

I have emailed my contact at Levetop the manufacturers of the LT7680A-R TFT controller IC to see what they make about the flickering. Hoping they can experiment with one! They are normally very helpful to me so we'll see what happens.
Hoping they can give me some definitive settings for the LT7680A-R and also the S7701.

Ian.

Hi Ian,
those symbols TLK, LTN and INFO from my picture are ghosts during flicker only, in a normal situation I have only AZERO and FRONT lit plus SMPL blinking. I have not been using GPIB yet except short test that it works, got ADVANTEST,R6581T,0,A01 response to *IDN? so the same as your.  I am just curious how come that e.g. INFO is lit during flicker stage when you never call it via SPI to be lit?

Regarding power supplies, I have measured power consumption of whole display including Blue Pill an it is just 1.1W so I doubt it can overload meter power supply if whole meter has 30W.  I will try to setup monitoring of incoming 5V to your board to see if there are any glitches.


Vladimir

I've added a another test HEX file whioch doesn't use SPI at all, so give it a go......it should just count upwards for the main TFT line.
The other test2.hex file will be useful to you also, as it _should_ report any VFD SPI errors. I never get any SPI errors so not easy to test.

PS. Have you tried another Blue Pill board.....just incase?

Ian.

[vf33184]

Interesting!
If you see ?? then it's either characters I haven't converted, or it's data corruption. In this case it's clearly data corruption. So I guess the incoming SPI data is somehow being corrupted.
I notice from your screenshot you are running GPIB at the time......I've tried hammering GPIB and see no issue here.
I notice also you have the INFO annunciator lit......whats that for?......I thought it was "unused" per the Japanese user manual.

On my units I never get ?? at the same moment as flickering, for me it's two different issues. Kind of leads me in this case to power supply dropping out on the LCD or BluePill. Might be worth adding further caps across teh +5VDC & +3.3VDC on my board.

I have just recently got saving to flash working so yes, I can make the 1VDC/1000mV modes more permanent for the user. I'll get to that soon.
*IDN? gives me ADVANTEST,R6581T,0,A01......not sure about my ADCMT branded unit.
With both, I get no flickering.......but like I have said it can appear for no reason, but mostly temperature issues.

I have emailed my contact at Levetop the manufacturers of the LT7680A-R TFT controller IC to see what they make about the flickering. Hoping they can experiment with one! They are normally very helpful to me so we'll see what happens.
Hoping they can give me some definitive settings for the LT7680A-R and also the S7701.

Ian.

Hi Ian,
those symbols TLK, LTN and INFO from my picture are ghosts during flicker only, in a normal situation I have only AZERO and FRONT lit plus SMPL blinking. I have not been using GPIB yet except short test that it works, got ADVANTEST,R6581T,0,A01 response to *IDN? so the same as your.  I am just curious how come that e.g. INFO is lit during flicker stage when you never call it via SPI to be lit?

Regarding power supplies, I have measured power consumption of whole display including Blue Pill an it is just 1.1W so I doubt it can overload meter power supply if whole meter has 30W.  I will try to setup monitoring of incoming 5V to your board to see if there are any glitches.


Vladimir

I've added a another test HEX file whioch doesn't use SPI at all, so give it a go......it should just count upwards for the main TFT line.
The other test2.hex file will be useful to you also, as it _should_ report any VFD SPI errors. I never get any SPI errors so not easy to test.

PS. Have you tried another Blue Pill board.....just incase?

Ian.

Hi Ian,
Here is my result using R6581_VS_Display_Test2.hex    It was running almost an hour. No errors reported, none flickering noticed. Should I run another HEX file too?

Don't have another BluePill now, will buy one.

Vladimir

[IanJ]

Hi Ian,
Here is my result using R6581_VS_Display_Test2.hex    It was running almost an hour. No errors reported, none flickering noticed. Should I run another HEX file too?

Don't have another BluePill now, will by one.

Vladimir

If you are saying you swap between the normal HEX file and TEST2 and you are getting issues with the normal HEX file and not with TEST2........then the fact I dropped the TFT update rate from 35ms to 100ms on TEST2 may be the fix!
I have attached a 100ms TFT refresh version of the normal HEX file.

Ian.

[vf33184]

Hi Ian,
Here is my result using R6581_VS_Display_Test2.hex    It was running almost an hour. No errors reported, none flickering noticed. Should I run another HEX file too?

Don't have another BluePill now, will by one.

Vladimir

If you are saying you swap between the normal HEX file and TEST2 and you are getting issues with the normal HEX file and not with TEST2........then the fact I dropped the TFT update rate from 35ms to 100ms on TEST2 may be the fix!
I have attached a 100ms TFT refresh version of the normal HEX file.

Ian.

Hi Ian,
unfortunately this 100ms version didn't fix the problem. Screen update rates is visibly slower, but still flickering, just less frequently. Again with ? symbols.

Vladimir

[IanJ]

Hi Ian,
unfortunately this 100ms version didn't fix the problem. Screen update rates is visibly slower, but still flickering, just less frequently. Again with ? symbols.

Vladimir

Does TEST2 display ?? At any time, and does it flicker?

Ian

[vf33184]

Hi Ian,
unfortunately this 100ms version didn't fix the problem. Screen update rates is visibly slower, but still flickering, just less frequently. Again with ? symbols.

Vladimir

Does TEST2 display ?? At any time, and does it flicker?

Ian

I didn't notice any ? symbol or flicker, have been testing both SPI enabled and SPI disabled firmware.

Vladimir

[IanJ]

I didn't notice any ? symbol or flicker, have been testing both SPI enabled and SPI disabled firmware.

Vladimir

So, the TFT SPI is ok, and for some reason then, you’re getting VFD SPI corruption. Perhaps try another BluePill just in case you have a dodgy I/O pin.
Try buying from a different supplier.

Ian

[vf33184]

I didn't notice any ? symbol or flicker, have been testing both SPI enabled and SPI disabled firmware.

Vladimir

So, the TFT SPI is ok, and for some reason then, you’re getting VFD SPI corruption. Perhaps try another BluePill just in case you have a dodgy I/O pin.
Try buying from a different supplier.

Ian

Hello Ian,

I have ordered new BluePill from different shop, should arrive early next week. I have also ordered another display and LCD driver board, it is somewhere on the way from China. When it arrives I will try to swap display or driver board too.

Regarding several SPI buses. Do I understand well that TFT SPI is a bus between display and display driver, and VFD SPI is between display driver and BluePill? If so, what exactly TEST2 HEX file is testing? I would like to understand it better to help me narrow down possible place of an issue I have. For now I am a bit shooting in the dark and trying to find the root cause.


Thank you.

Vladimir

[IanJ]

Hello Ian,

I have ordered new BluePill from different shop, should arrive early next week. I have also ordered another display and LCD driver board, it is somewhere on the way from China. When it arrives I will try to swap display or driver board too.

Regarding several SPI buses. Do I understand well that TFT SPI is a bus between display and display driver, and VFD SPI is between display driver and BluePill? If so, what exactly TEST2 HEX file is testing? I would like to understand it better to help me narrow down possible place of an issue I have. For now I am a bit shooting in the dark and trying to find the root cause.

TEST2 is primarily for testing the LCD without actually capturing VFD SPI data. It uses the VFD SPI routine only to trigger writing to the LCD.
You should see the MAIN line and AUX line count upwards at different rates, the MAIN line should count slower.
Both should be very even counting, no long pausing or resetting to zero etc.
The very bottom line will report VFD SPI issues if they are received.

The flickering issue is not related to SPI data, it's an issue with the actual TFT drive from the LT7680 driver board and the TFT LCD.

If you are getting ?? on MAIN or AUX using TEST2 then that indicates a fundemental issue with the Blue Pill and likely nothing to do with the SPI data being captured.

If you get good counting on AUX and MAIN using TEST2 then the problem is with the captured VFD SPI data.

For info, there are actually 3 SPI interfaces being used on the Blue Pill:
SPI1 = Full duplex SPI MASTER to the driver board. This is used to set up and write to memory in the LT7680A-R driver IC which is then in turn passed to the TFT.
SPI2 = This is an SPI SLAVE used to capture data from the R6581 display board.
SPI(bitbang) = This is an SPI MASTER connected to the TFT itself (COG chip on glass) and is used once at startup to set up the actual TFT itself. Written once only.

Ian.

[vf33184]

TEST2 is primarily for testing the LCD without actually capturing VFD SPI data. It uses the VFD SPI routine only to trigger writing to the LCD.
You should see the MAIN line and AUX line count upwards at different rates, the MAIN line should count slower.
Both should be very even counting, no long pausing or resetting to zero etc.
The very bottom line will report VFD SPI issues if they are received.

The flickering issue is not related to SPI data, it's an issue with the actual TFT drive from the LT7680 driver board and the TFT LCD.

If you are getting ?? on MAIN or AUX using TEST2 then that indicates a fundemental issue with the Blue Pill and likely nothing to do with the SPI data being captured.

If you get good counting on AUX and MAIN using TEST2 then the problem is with the captured VFD SPI data.

For info, there are actually 3 SPI interfaces being used on the Blue Pill:
SPI1 = Full duplex SPI MASTER to the driver board. This is used to set up and write to memory in the LT7680A-R driver IC which is then in turn passed to the TFT.
SPI2 = This is an SPI SLAVE used to capture data from the R6581 display board.
SPI(bitbang) = This is an SPI MASTER connected to the TFT itself (COG chip on glass) and is used once at startup to set up the actual TFT itself. Written once only.

Ian.

Hello Ian,
thank you for very good description of different SPI buses and its function.

I have been running TEST2 HEX file again, this time more than 24 hours.  MAIN display counted 1 million and AUX display 6.5 million samples, VFD SPI report no errors (see picture). Counting is very smooth without any interruption, haven't noticed any glitches or flickers.

But with regular firmware some symbols are sometimes being replaced by "?" (shown on picture in my previous messages) just probably for single display refresh cycle, next cycle it's being corrected. Based on your description it would lead me to conclusion that:
a) no issue on communication between BluePill and LT7680A-R driver
b) no issue on communication between BluePill and TFT COG
c) issue with data being spied on SPI link between main meter CPU and Hitachi CPU on display board. If so, then I don't know why TEST2 firmware reports "VFD SPI - no errors". I don't know how do you evaluate issue on VFD SPI, if each data batch has some parity check or some other mechanism?

If there is corrupted data at VFD SPI input, BluePill replace unknown symbol by "?" and send it to TFT or BluePill sends unknown received character down to TFT and then TFT itself replace unknown character by "?" symbol?

Sorry for many questions, I am just trying to find out where is my problem. 

Thank you.

Vladimir

[IanJ]

Hello Ian,
thank you for very good description of different SPI buses and its function.

I have been running TEST2 HEX file again, this time more than 24 hours.  MAIN display counted 1 million and AUX display 6.5 million samples, VFD SPI report no errors (see picture). Counting is very smooth without any interruption, haven't noticed any glitches or flickers.

But with regular firmware some symbols are sometimes being replaced by "?" (shown on picture in my previous messages) just probably for single display refresh cycle, next cycle it's being corrected. Based on your description it would lead me to conclusion that:
a) no issue on communication between BluePill and LT7680A-R driver
b) no issue on communication between BluePill and TFT COG
c) issue with data being spied on SPI link between main meter CPU and Hitachi CPU on display board. If so, then I don't know why TEST2 firmware reports "VFD SPI - no errors". I don't know how do you evaluate issue on VFD SPI, if each data batch has some parity check or some other mechanism?

If there is corrupted data at VFD SPI input, BluePill replace unknown symbol by "?" and send it to TFT or BluePill sends unknown received character down to TFT and then TFT itself replace unknown character by "?" symbol?

Sorry for many questions, I am just trying to find out where is my problem. 

Thank you.

Vladimir

You've got it right.....just to add that the SPI errors thats can be reported are probably rather limited. It's a built in mechanism I am am not 100% sure of all the failure modes it can report on.
Can you post a photo of the termination of the 3 wires down onto the R6581 display board.

Ian.

[vf33184]

Hello Ian,
thank you for very good description of different SPI buses and its function.

I have been running TEST2 HEX file again, this time more than 24 hours.  MAIN display counted 1 million and AUX display 6.5 million samples, VFD SPI report no errors (see picture). Counting is very smooth without any interruption, haven't noticed any glitches or flickers.

But with regular firmware some symbols are sometimes being replaced by "?" (shown on picture in my previous messages) just probably for single display refresh cycle, next cycle it's being corrected. Based on your description it would lead me to conclusion that:
a) no issue on communication between BluePill and LT7680A-R driver
b) no issue on communication between BluePill and TFT COG
c) issue with data being spied on SPI link between main meter CPU and Hitachi CPU on display board. If so, then I don't know why TEST2 firmware reports "VFD SPI - no errors". I don't know how do you evaluate issue on VFD SPI, if each data batch has some parity check or some other mechanism?

If there is corrupted data at VFD SPI input, BluePill replace unknown symbol by "?" and send it to TFT or BluePill sends unknown received character down to TFT and then TFT itself replace unknown character by "?" symbol?

Sorry for many questions, I am just trying to find out where is my problem. 

Thank you.

Vladimir

You've got it right.....just to add that the SPI errors thats can be reported are probably rather limited. It's a built in mechanism I am am not 100% sure of all the failure modes it can report on.
Can you post a photo of the termination of the 3 wires down onto the R6581 display board.

Ian.

Hello Ian,
here is the picture of wiring between R6581 front panel board and new display board.

There is still a question, when there are corrupted data at VFD SPI input, BluePill replace unknown symbol by "?" and send it to TFT or BluePill sends unknown received character down to TFT and then TFT itself replace unknown character by "?" symbol?

Thank you.

Vladimir

[coromonadalix]

good questions,  could be the interface pcb for the vfd who could spit ?   because there was some error ? or miss interpretation ?  drop in the spi data flow ?

noise on the supply line,  would you try to add an 0.1uf   on the 5v vcc line   could help

for the 3 small wires, could they catch some noise ?  i would have tried to match their lenght ?

[IanJ]

Hello Ian,
here is the picture of wiring between R6581 front panel board and new display board.

There is still a question, when there are corrupted data at VFD SPI input, BluePill replace unknown symbol by "?" and send it to TFT or BluePill sends unknown received character down to TFT and then TFT itself replace unknown character by "?" symbol?

Thank you.

Vladimir
[/quote]

Blue Pill code, data coming in from the R6581 is checked against a bitmap/ASCII table.
Example:
If this is received then it maps it to 0x34 which is the number 4
{{0x02, 0x06, 0x0A, 0x12, 0x1F, 0x02, 0x02}, '4'},  // 0x34, 4

If there is no match then "?" is returned and thats is what is passed to the LT7680A-R.

Can you scope V-SCK, V-SDA, V-RESTART and the +5V supply.

Also, see Post #1 at the top (or attached), there is an issue with one of the versions of PCBs that require a track cut to avoid a short on my PCB (my mistake in the Gerbers). Saying that I assume you've done that because with the short the display is blank.

Ian.

[jj131415]

hi Ian,
Maybe something is missing during the SPI character capture from R6581 front panel. I don't know if it caused by SPI interrupt and conversion time of STM32 MCU. If let R6581 run internal calibration, it's easily to see "?".

[IanJ]

 

hi Ian,
Maybe something is missing during the SPI character capture from R6581 front panel. I don't know if it caused by SPI interrupt and conversion time of STM32 MCU. If let R6581 run internal calibration, it's easily to see "?".

I hear you, but it works for many other people without this issue.
Are you running the latest firmware on the Blue Pill.....?

It just looks like it's SPI corruption on the VFD SPI........but I guess it could be intermittent on the TFT SPI or even the LCD itself.
If you have tried another Blue Pill/LT7680 driver board then I guess I could take a look at your setup if you ship me my board c/w BluePill, LT7680 driver & TFT (at your cost both ways). I'm in the UK.

Ian.

[IanJ]

Hi all,

Just an observation……with the latest firmware and using the BuyD config I notice flicker returns when my aircon switched off and the temp rose to 24.8degC…….then stopped flickering once temps reduced……so definitely the LT7680 driver or TFT itself hates the heat.
More investigation required.

Meanwhile my 2nd R6581T had no such issue and has never, ever flickered. Rock stable.

Ian

[vf33184]

Hello Ian,
here is the picture of wiring between R6581 front panel board and new display board.

There is still a question, when there are corrupted data at VFD SPI input, BluePill replace unknown symbol by "?" and send it to TFT or BluePill sends unknown received character down to TFT and then TFT itself replace unknown character by "?" symbol?

Thank you.

Vladimir

Blue Pill code, data coming in from the R6581 is checked against a bitmap/ASCII table.
Example:
If this is received then it maps it to 0x34 which is the number 4
{{0x02, 0x06, 0x0A, 0x12, 0x1F, 0x02, 0x02}, '4'},  // 0x34, 4

If there is no match then "?" is returned and thats is what is passed to the LT7680A-R.

Can you scope V-SCK, V-SDA, V-RESTART and the +5V supply.

Also, see Post #1 at the top (or attached), there is an issue with one of the versions of PCBs that require a track cut to avoid a short on my PCB (my mistake in the Gerbers). Saying that I assume you've done that because with the short the display is blank.

Ian.

Hello Ian,
yes, I have PCB version 1.1 what is affected by that Gerber error what caused blank screen at the beginning of my display replacement process, but I already cut that shortening traces and display start working.

In a meanwhile I have added 100nF capacitor on 5V input and modified wiring between BluePill and VFD board (all three wires twisted with different routing) but it didn't fix the problem. See attached picture.
   
One of your ideas was that BluePill itself can be an issue therefore I have ordered new one from different source. It has already arrived (has different reset button and both LEDs are red) and I started with its programming. Immediately I have noticed one difference, new BluePill was programed much faster (just in 1.5s) compared to old one (3s). I am using ST-LINK V2 USB dongle and ST-LINK UTILITY software. What is your typical programming time?

There is one more difference. You previously mentioned that your BluePill has 64kB flash, but both of mine have 128kB, not sure if this doesn't indicate they are counterfeit?

Then I tried new BluePill on display board. During one day of continuous running I haven't notice any "?" symbol. So far so good.

But then I start playing with Menu and noticed that when I am moving by arrows between different Menu items (e.g. calibration, beeper, GPIB etc) sometimes very shortly "?" symbol appears in place of some letter of submenu what is blinking. Other items what are not blinking never have this issue. Then I tried to run internal calibration. During its execution there is INT CALIBRATION blinking on display. I have noticed that "?" symbol sometimes shows (again very shortly), but also that frequency of blinking is fluctuating a bit. Also sometimes whole "INT CALIBRATION" light up at the same moment, sometimes "LIBRATION" and fraction of second later also "INT CA" lights up. I recorded slow-motion video and this behavior is clearly visible. Similarly when I am measuring e.g. voltage, digits are sometimes being updated not at the same time but in different order (I mean that 7th digit is updated and then 5th digit).

Here is video I recorded showing display behavior described above:  https://youtu.be/GlcbgusXKIo

Maybe I am just too sensitive about these display artifacts and most of users will not notice it. Maybe I have some issue with hardware. Or maybe there is some imperfection in the way how data are being processed by BluePill and/or LDC driver or LCD itself.  BluePill being too much loaded? Or timing issue on one of SPIs? Or maybe there is the other way how display updates should be commanded in some bulks to have whole display updated at the same moment instead of individual symbols?

I am trying to explain as good as possible what I see. I can be completely wrong. Or it can help you to find the issue and implement some data corruption identification and correction mechanism in software, or different display handling procedure. You mentioned waiting for additional details from LT7680A-R producer, that can help too.

Thank you.

Vladimir

Note: all tests made with 26-01-25 HEX file and default BuyD setting.

[IanJ]

First thing I noticed in your photo is you have twisted the small wires together, that can cause crosstalk. Please untwist them.

The TFT should be a beautiful experience, with virtually no artefacts (? Etc). I will try INT CALIBRATING on mine later today and let you know how mine performs.

64k/128k are just two options for the Blue Pill. I have always used the 64k version.

Ian.

UPDATE: INT CALIBRATING display works perfectly, alternating blank and the text.

[jj131415]

hi Ian,
I'm using the FW is 26th Jan '25 version, but this "?" also can be seen in several previous FW during INT CALIBRATING. Thanks.

[IanJ]

hi Ian,
I'm using the FW is 24th Jan '25 version, but this "?" also can be seen in several previous FW during INT CALIBRATING. Thanks.

I don’t really know why INT CALIBRATING displays phantom “?” When other screens don’t. Might be the R6581 data timing is slightly different if the R6581 is under its own CPU load.
I’ll take a look at the acquisition code, see if any improvements can be made.

[jj131415]

hi Ian,
I take a video on it, so I can capture this momentary "?" picture, it's very fast and easily to ignore it. Thanks.

[vf33184]

hi Ian,
I take a video on it, so I can capture this momentary "?" picture, it's very fast and easily to ignore it. Thanks.

See my previous post where I have link to slow motion video on youtube I have recorded to show this behavior with “?” symbol.

[IanJ]

hi Ian,
I take a video on it, so I can capture this momentary "?" picture, it's very fast and easily to ignore it. Thanks.

See my previous post where I have link to slow motion video on youtube I have recorded to show this behavior with “?” symbol.

Have you untwisted the 3 wires as I mentioned above?
Crosstalk on the SPI could very well be the problem with your display…….which I think is a different problem here.

Ian

[vf33184]

hi Ian,
I take a video on it, so I can capture this momentary "?" picture, it's very fast and easily to ignore it. Thanks.

See my previous post where I have link to slow motion video on youtube I have recorded to show this behavior with “?” symbol.

Have you untwisted the 3 wires as I mentioned above?
Crosstalk on the SPI could very well be the problem with your display…….which I think is a different problem here.

Ian

Hi Ian,
yes, I have untwisted those 3 SPI VFD wires, still the same behavior what I have recorded on youtube video.

Vladimir

[jj131415]

hi Ian,
They are not twisted together.

[IanJ]

I’ll have a look at the code next few days, I ran INT CALIBRATING a few times and can see a screen anomaly albeit nothing like the YT demo uploaded.

Here's my own video, I don't really see any "?" but I notice the way it updates the display, sometimes in one go, sometimes you see a few chars at a time. I don't know if this is related to the "?" issue but worth exploring.
https://www.youtube.com/shorts/Zh2gXrGFRAs

Ian.

[IanJ]

Hi all,

Attached to this post is a test .HEX file.

I have revised some timing & interrupts to help the TFT have the time and resources necessary to write to the TFT.

Could anyone who is experiencing "?" being displayed randomly please test it out and report back.
(I don't really have the issue on both my R6581T's so unsure what difference it will make, if any)

Ian.

[vf33184]

Hi all,

Attached to this post is a test .HEX file.

I have revised some timing & interrupts to help the TFT have the time and resources necessary to write to the TFT.

Could anyone who is experiencing "?" being displayed randomly please test it out and report back.
(I don't really have the issue on both my R6581T's so unsure what difference it will make, if any)

Ian.

Hello Ian,
I will test new firmware during weekend, first I need to mount my meter back together.

In a meanwhile I would ask for one clarification about previous R6581_VS_DisplayTestTFTonly1.hex testing file. You are writing that it is not using VFD SPI but just TFT SPI. I am still trying to troubleshoot my display upgrade so I have ordered another set of TFT and display driver and also populated second your PCB. However when I am testing it on the bench without connection to meter, display is initiated (backlight is on) but not displaying anything.

Should R6581_VS_DisplayTestTFTonly1.hex work without connected VFD SPI? Or it still needs VFD SPI signals being connected to trigger displaying counting even just TFT SPI counts on the display? It seems to me that VFD SPI needs to be connected to enable software to run. It behaves the same on both of my TFT+driver+BluePill sets what I am testing on the bench.

Thank you.

Vladimir

[IanJ]

Hello Ian,
I will test new firmware during weekend, first I need to mount my meter back together.

In a meanwhile I would ask for one clarification about previous R6581_VS_DisplayTestTFTonly1.hex testing file. You are writing that it is not using VFD SPI but just TFT SPI. I am still trying to troubleshoot my display upgrade so I have ordered another set of TFT and display driver and also populated second your PCB. However when I am testing it on the bench without connection to meter, display is initiated (backlight is on) but not displaying anything.

Should R6581_VS_DisplayTestTFTonly1.hex work without connected VFD SPI? Or it still needs VFD SPI signals being connected to trigger displaying counting even just TFT SPI counts on the display? It seems to me that VFD SPI needs to be connected to enable software to run. It behaves the same on both of my TFT+driver+BluePill sets what I am testing on the bench.

Thank you.

Vladimir

No, I only tweaked the existing SPI for the TFT interface is what I meant. Everything is the same.

SPI1 = VFD data capture
SPI2 = TFT LCD drive
SPI3(bitbang) = TFT LCD COG initialization.

Next, I will start looking at how I can modify MickleT's VFD capture code to help it fit better with my code and capture R6581 data more reliably......because this is where I think the random "?" problem is.

Ian.

[vf33184]

Hello Ian,
I will test new firmware during weekend, first I need to mount my meter back together.

In a meanwhile I would ask for one clarification about previous R6581_VS_DisplayTestTFTonly1.hex testing file. You are writing that it is not using VFD SPI but just TFT SPI. I am still trying to troubleshoot my display upgrade so I have ordered another set of TFT and display driver and also populated second your PCB. However when I am testing it on the bench without connection to meter, display is initiated (backlight is on) but not displaying anything.

Should R6581_VS_DisplayTestTFTonly1.hex work without connected VFD SPI? Or it still needs VFD SPI signals being connected to trigger displaying counting even just TFT SPI counts on the display? It seems to me that VFD SPI needs to be connected to enable software to run. It behaves the same on both of my TFT+driver+BluePill sets what I am testing on the bench.

Thank you.

Vladimir

No, I only tweaked the existing SPI for the TFT interface is what I meant. Everything is the same.

SPI1 = VFD data capture
SPI2 = TFT LCD drive
SPI3(bitbang) = TFT LCD COG initialization.

Next, I will start looking at how I can modify MickleT's VFD capture code to help it fit better with my code and capture R6581 data more reliably......because this is where I think the random "?" problem is.

Ian.

Hi Ian, yes, I understand this. 

My question was related to testing hex file R6581_VS_DisplayTestTFTonly1 what was released like month ago. The question was if it needs valid incoming VFD SDI data to run the code or not. 

I have BluePill+driver+TFT combo on the bench connected just to lab 5V power supply and the code is not running (nothing on display just back-light on), and my conclusion is that the code really needs valid incoming VFD SPI data for running, regardless it is not using those data at all. If so, then it explains the behavior I see, and it means that using the code for bench only testing is not possible. 

Thank you.

Vladimir

[IanJ]

Hi Ian, yes, I understand this. 

My question was related to testing hex file R6581_VS_DisplayTestTFTonly1 what was released like month ago. The question was if it needs valid incoming VFD SDI data to run the code or not. 

I have BluePill+driver+TFT combo on the bench connected just to lab 5V power supply and the code is not running (nothing on display just back-light on), and my conclusion is that the code really needs valid incoming VFD SPI data for running, regardless it is not using those data at all. If so, then it explains the behavior I see, and it means that using the code for bench only testing is not possible. 

Thank you.

Vladimir

Ahhh sorry, I misread..........(I'm busy writing .py for Home Assistant right now!)

> Test HEX files:
> R6581_VS_Display_Test2.hex
> Test writing to the TFT LCD without actual VFD SPI data but actions when a VFD SPI packet is received.
> This initial version will count each time the TFT is updated on the MAIN display, and on the AUX display it will count each time data is captured from the R6581 SPI bus.
> Any VFD SPI error codes are reported. TFT LCD refresh is set to 100ms. See R6581_VS_Display_Test2.hex attachment below.

> R6581_VS_DisplayTestTFTonly1.hex
> TFT counter only, VFD SPI is disabled.

My memory is bad.....but from my notes, R6581_VS_DisplayTestTFTonly1.hex, you should get something without VFD data (disabled VFD SPI). It just writes to the TFT.
I can't confirm as I don't have that standalone setup handy.

Ian.

[IanJ]

Hi all,

Attached to this post 3 test .HEX files.

I have further revised some timing, DMA & interrupts to help the TFT have the time and resources necessary to write to the TFT, and the VFD capture.

R6581_VS_Display_21_02_25_test1.hex
Pausing VFD SPI2 whilst writing to the TFT:

R6581_VS_Display_21_02_25_test2.hex
As above but with additional pausing TFT SPI1 whilst capturing/processing VFD data.

R6581_VS_Display_21_02_25_test3.hex
As both above but with additional disable of FIFO check when sending to the TFT.

Could anyone who is experiencing "?" being displayed randomly please test them out and report back.
(I don't really have the issue on both my R6581T's so unsure what difference it will make, if any)

Ian.

[vf33184]

Hi Ian, yes, I understand this. 

My question was related to testing hex file R6581_VS_DisplayTestTFTonly1 what was released like month ago. The question was if it needs valid incoming VFD SDI data to run the code or not. 

I have BluePill+driver+TFT combo on the bench connected just to lab 5V power supply and the code is not running (nothing on display just back-light on), and my conclusion is that the code really needs valid incoming VFD SPI data for running, regardless it is not using those data at all. If so, then it explains the behavior I see, and it means that using the code for bench only testing is not possible. 

Thank you.

Vladimir

Ahhh sorry, I misread..........(I'm busy writing .py for Home Assistant right now!)

> Test HEX files:
> R6581_VS_Display_Test2.hex
> Test writing to the TFT LCD without actual VFD SPI data but actions when a VFD SPI packet is received.
> This initial version will count each time the TFT is updated on the MAIN display, and on the AUX display it will count each time data is captured from the R6581 SPI bus.
> Any VFD SPI error codes are reported. TFT LCD refresh is set to 100ms. See R6581_VS_Display_Test2.hex attachment below.

> R6581_VS_DisplayTestTFTonly1.hex
> TFT counter only, VFD SPI is disabled.

My memory is bad.....but from my notes, R6581_VS_DisplayTestTFTonly1.hex, you should get something without VFD data (disabled VFD SPI). It just writes to the TFT.
I can't confirm as I don't have that standalone setup handy.

Ian.

Hello Ian,
I have got in trouble. I made many changes to find that random issue, but now my setup stopped working at all.

Actual behavior:
1. When I start my meter, I can see (using oscilloscope) communication on LCM.SCK, LCM.MOS1, LSM.MIS0 and LSM.CS. I guess this is SPI3 bus for COG on TFT.
2. After like 2 seconds communication stops and LCD backlight is on, and there is horizontal and vertical white line on screen (see picture). As you described in one of your previous messages this should be proper behavior as display just needs to be initiated once.
3. and that's it, nothing more displayed

I am probing different signal:
1. SPI VFD data (V.SDA, V.SCK and V.RESTART) - I can see communication on all 3 lines
2. L.SCK, L.DIN and L.CS (this should be SPI2 = SPI TFT) - there is no communication at all and this is the reason why LCD is blank (except those two while lines), also green LED on BluePill is not blinking. Should it be blinking when receiving valid VFD data?

I have two suspicions what has happened:

1. my ST-LINK V2 programmer is not working properly and either programmed BluePill incorrectly or even killed that partially - I already have 3 pieces of BluPills and they behave the same way now
2. I tried service menu on R6581 - during turn-on hold HOME button. And then I initiated display test what was working. But during next turn-on I was not able to initiate this service menu any more and after few tries to reprogram BluPills, now display is not working any more

I have ordered another BluePill and also ST-LINK to try again, this should address suspicion 1.

Can you try service menu described in suspicion 2 if it works properly for you, please?

Sorry, I am not able to test those new HEX files you created with different TFT timing until I resolve my issue.

Thank you.

Vladimir

PS: I have two sets of display-driver-your board and 3 BluePills, all combinations behave the same.

[IanJ]

When you initiate Power on with HOME, you need to release the HOME button quickly after power up, if you hold the HOME button on too long and release it then the DIAG menu does not appear.
I presume it does this with the original VFD also.

For you main problem, you are checking things properly.....all connections in the right place: 3 signals +5v, GND. etc.

I presume you have checked ST-LINK Utility app settings incase you changed anything by accident?

You could try updating the firmware in your ST-LINK V2. I do remember I had to update the firmware in my V3 before it would work properly.

If you really get nowhere and have tried everything then you can send your LCD, R6581 Pcb & BluePill to me and I will try it on my R6581......and return to you.

Ian.

[vf33184]

When you initiate Power on with HOME, you need to release the HOME button quickly after power up, if you hold the HOME button on too long and release it then the DIAG menu does not appear.
I presume it does this with the original VFD also.

For you main problem, you are checking things properly.....all connections in the right place: 3 signals +5v, GND. etc.

I presume you have checked ST-LINK Utility app settings incase you changed anything by accident?

You could try updating the firmware in your ST-LINK V2. I do remember I had to update the firmware in my V3 before it would work properly.

If you really get nowhere and have tried everything then you can send your LCD, R6581 Pcb & BluePill to me and I will try it on my R6581......and return to you.

Ian.

Hello Ian,
in a meanwhile I did following steps:
- ordered another Bluepills (I have already 5 pcs) and ST-LINK v2
- programmed Bluepill with new ST-LINK v2 - I have tried both STM32CubeProgrammer and ST-LINK Utility software
- tried different BluePills with different firmware versions and TFTs and driver boards
Unfortunately it still doesn't work. 
 
I believe that firmware is being properly programmed to BluePill because TFT is being initialed (TFT back-light gets on after turn the meter on). I can in oscilloscope that VFD SPI data are coming on input pins of BluePill. Unfortunately TFT SPI is absolutely silent, not signals coming out. I am just curious how this can happen? I am not sure how TFT SPI is being initialized on your code, if it checks validity of input VFD SPI data and if those are seeing not valid, then TFT SPI is silent?
On Oscilloscope I can't recognize if VFD SPI data are valid, I can just see that signal is coming in.

I am thinking about last test what I can do. I can solder back (it won't be simple) VFD display (it is weak but still a bit visible). If it works, then VFD SPI data must be valid and problem is somewhere in BluePill-driver-TFTdisplay). If VFD wont work, than something got broken within front panel Hitachi CPU of main CPU board.

Would you be so kind and check your R6581_VS_DisplayTestTFTonly1.hex code if it is really running even without presence of valid incoming VFD SPI data?

 Thank you.

Vladimir
 

[IanJ]

Vladimir,

I can only suggest you run the latest code, try press DCV on power up to get the LCD config options, and if you are not getting that and not getting anything on the LCD in normal operation.......then ship me your Pcb with the Blue Pill & LCD and I will test on my R6581T here....once my 24/7 test is completed.

If you try with the VFD fitted again, then you CAN run the VFD and my Pcb at the same time (dual display).

Or,

I can ship you a programmed Blue Pill (albeit untested because I am running 24/7......but it will be fine).

Ian.

[GRMPhD]

Hi Ian!

I finally got my display in the mail and it’s installed and working nicely!

A few things I’ll point out to anyone who wants to try it are:
1: The first blue pills I bought on Amazon that came with the programmer did not have enough flash memory to program the hex file which is ~100k. They only had 32k. So I had to buy another one. Make sure you get a real one!
2: When I first powered up the screen I just got a black screen with a few racing dots along the edge no matter what I did. This happened even with the test programs. I checked the SCL, SDA, and Reset lines with the scope and everything looked fine. However, when I did this I had not yet connected the wires to the DCV button because I was eager to see something. Once I connected them everything started working fine.

I’ve had this meter since 2019 and have barely used it since the display was so dim. I even tried rejuvenating the VFD and had no luck. Now it can actually get some use!

Thanks for making this project free and open!
Geoff

Here are some before and after pictures:

[IanJ]

Thanks GRMPhD, I have updated the instructions in post #1 to mention that the DCV switch hook-up is no longer optional.
Enjoy your R6581T and its beautiful display. I'm betting like me you turn on the DMM even though you are not necessarily using it....:-)

A 32k BluePill would certainly fail to program, Visual Studio reports:
Flash req'd = 37KB out of 64KB (58%), SRAM req'd =3688 bytes out of 20KB (18%)

I have also removed the TEST hex files from post #1, I think they were a bit more trouble than they were worth as they had a few caveats!

Ian.

[vf33184]

Thanks GRMPhD, I have updated the instructions in post #1 to mention that the DCV switch hook-up is no longer optional.
Enjoy your R6581T and its beautiful display. I'm betting like me you turn on the DMM even though you are not necessarily using it....:-)

A 32k BluePill would certainly fail to program, Visual Studio reports:
Flash req'd = 37KB out of 64KB (58%), SRAM req'd =3688 bytes out of 20KB (18%)

I have also removed the TEST hex files from post #1, I think they were a bit more trouble than they were worth as they had a few caveats!

Ian.

Hello Ian,
I can confirm finding of GRMPhD about mandatory DCV button wiring presence.

What I tested:
- firmware from December 27th (before DCV feature was introduced) and disconnected DCV - display works
- firmware from  January 26th and disconnected DCV - display doesn't work
- firmware from  January 26th and connected DCV - display works
- testing firmware (both VFD SPI enabled and disabled) and disconnected DCV - display doesn't work
- testing firmware (both VFD SPI enabled and disabled) and connected DCV - display works

Anyhow, thanks to this finding my display is working again and I can continue testing latest beta firmware potentially addressing TFT refresh issue. Will report it back.

Thank you Ian and GRMPhD.

Vladimir

[IanJ]

Hello Ian,
I can confirm finding of GRMPhD about mandatory DCV button wiring presence.

Ahhhh!......I thought you had the DCV button connected all this time......I mentioned using the DCV button on one of my posts above.
Oh well, at least you are back on track.

The latest current firmware has a lot of tweaks over the original and including the TEST versions.....so any testing please do it on the latest firmware and don't forget you can hold the DCV button in to bring up the TFT config options screen.

Ian.