SSD1322 macro crashes FC7 test

[Dutch]

I'm in the middle of making a gLCD display work with the SSD1322 controller. unfortunate i cant find what is wrong at his moment but did anybody got a similar display like this working?

Anyway what I want to ask of current Flowcode7 users and if they have the Display package. Is if they could try to assemble next file (in hex, the middle option) and see it it normally proceeds. mine doesn't...

thanks for trying and letting know!
Regards Angelo.

[EtsDriver]

Hi Angelo,

I got it too to crash on my system.

--> Take a look at your 3d view, move the ssd1322 away... Under there, is another display (accidentally added?).
--> Remove other one and try again to compile hex. Should now compile without crashing!

Best Regards;
Jari

[Dutch]

Thank you Jari for the test. can you try the SSD1622 by itself again I posted now. this is the macro creating the problem on mine. if its on yours too I can let a moderator know.

[Benj]

Hello,

Is that a v8 program? it seems to be due to it's target device.

It's compiling for me using the latest version 8.2 and the latest component updates.

v7 program also working ok for me and compiling correctly. What version of v7 are you running?

[maharadga]

And with me Flowcode 7 crash with project file above, if I try compile it.
I use Fc version 7.3.0.7 with all updates.

[Dutch]

Ben, I have run the latest updates as per your link. it says 7.3.0.7
I cant find a recent date for the SSD1322 in the update files, though but I could be wrong there. maybe its hidden.

pretty sure I did build it in V7 but I rebuild the 2 macro's in a same simple example just minutes ago and same result. I use the Atmel Atmega328P because its easy and I have a few. But even if I take a PIC16F887 for example its still crashing.
If you want to look with Teamviewer on my pc im oke with that.

can you confirm the 'buffered' SSD1322 macro is designed for the serial SPI-4 mode of that display driver?

[Benj]

Hello,

I get this when trying to compile in v7.3.

Target folder: C:\Users\BenR\Desktop
Source name: C:\Users\BenR\Desktop\SSD1622_newtest_8080.fcfx
Title:
Description:
Device: PIC.16F.16F887
Generated by: Flowcode v7.3.0.7
Date: Wednesday, January 29, 2020 17:51:55
Users: 1
Registered to: Dev User
Licence key: HJVC24
NOT FOR COMMERCIAL USE
http://www.matrixtsl.com
Launching the compiler...
D:\Flowcode 7\compilers\pic\bin\xc8.exe --chip=16F887 "SSD1622_newtest_8080.c" --MSGDISABLE=359,1273,1388 --FLOAT=32 --DOUBLE=32
Microchip MPLAB XC8 C Compiler (Free Mode) V1.41
Build date: Jan 24 2017
Part Support Version: 1.41
Copyright (C) 2017 Microchip Technology Inc.
License type: Node Configuration

using updated 32-bit floating-point libraries; improved accuracy might increase code size
SSD1622_newtest_8080.c: 691: (764) mismatched comparison (warning)
SSD1622_newtest_8080.c: 1865: (1393) possible hardware stack overflow detected; estimated stack depth: 9 (warning)
.

Memory Summary:
Program space used F1Bh ( 3867) of 2000h words ( 47.2%)
Data space used 74h ( 116) of 170h bytes ( 31.5%)
EEPROM space used 0h ( 0) of 100h bytes ( 0.0%)
Data stack space used 0h ( 0) of 60h bytes ( 0.0%)
Configuration bits used 2h ( 2) of 2h words (100.0%)
ID Location space used 0h ( 0) of 4h bytes ( 0.0%)

This is potentially interesting.

SSD1622_newtest_8080.c: 1865: (1393) possible hardware stack overflow detected; estimated stack depth: 9 (warning)

Is your compiler version the same? You can check the output by viewing the .msg.txt file produced in the project folder.

Just trying to figure out what might be causing the crash. Can you compile to C without crashing?

[Dutch]

It doesn't even get that far. if I either press compile to C or Hex or even the direct to processor it freezes a few seconds and then it crashes.

I see the wild chosen PIC example is a wrong one. the pic16F887 is not suitable even if it would build!. hence the stack overflow.
please test the macro with the ATmega328P. i get it to crash even if i only put the display in the 3D window already.

[Benj]

I wonder if it's a file permissions or path problem. Can you create a blank project in the same folder and compile that to C?

[Dutch]

tested that. works. i mean that always have worked for the last years with all other projects. (many compilations and walking back and forth to main PC ) just now when i specifically take the SSD1322 it crashes.

i took a recording il try to add.

[Dutch]

received two screens yesterday with SSD1306 i2c and wrote a simple flowcode and compiled and worked fine.

anything found on the SSD1322 ?

[Benj]

Hello,

Please can you try these components, I've re-built them using v7 and can't see anything in them that would cause a crash but maybe this will solve the problem for you?

gLCD_SSD1322.fcpx

(33.11 KiB) Downloaded 281 times

gLCD_SSD1322_buffered.fcpx

(9.28 KiB) Downloaded 302 times

If not then do both components cause a crash. e.g. if you have only one or the other of the components in a project do you still get the crash?

[Dutch]

Tested the 're-build' gLCD_SSD1322 and now it compiles oke! i say insert these in the last update combination . Thank you Ben!

unfortunate my LCD screen is exactly reacting the same as the last FC8 i could compile so i suspect the screen is broken. there was some confusion on my side if the screen is 3,3 or 5 volt and i started too high. il order a new.

No until this moment no other components did cause this. just the one SSD1622 parallel.

[Dutch]

Soooo I received my new gLCD 3,12'' oled display with SSD1322 because I thought I fried the other one and hooked all up on 3 volt as per datasheet.
but, unfortunately still no good. I tested both possibility's of connecting. parallel 8080 and the SPI-3 serial/buffered.
both ways same 'noise' on the screen. the oscilloscope does show data on the 4 lines but don't know if its correct. have nothing to compare it to.
I have a part still on its way to transform 5v signals to 3volt but the ATmega328P still work at 3 volts so that cant be the issue. I think...

I have a loop of showing a circle a second and clear it a second long. I don't see any of the switching back in the signals.

anybody had luck building a working display with this macro? I did a few other types of displays with other macros and all fine.
anybody of the staff who can advice me what to do or can check this? I was really hoping this was going to work.

Angelo.

[Dutch]

oke I found a weird thing... I added the led connected to B5 on this board to the 1 second on off cyclus and it wont flash it simulates in FC though..
if I disable the 3 macro's in the same FCfile and compile it and load it on the board it flashes.... like with all normally enable it 'hangs' in the first macro's initialisation... if I set display jumpers according the data type and use that macro (parallel 8080 or buffered) it shows only then correct matched the noise on the display. if it is not set correct it wont display the noise also.. so its apparently the initialization macro is 'starting' in the right direction for the correct output pins .. but not send the correct data to the display eventually?

that picture of the scope is repeating like that from the start. this is on CS and serial clock. the others give even less data what seems odd for a data pin. but could be wrong.

[Benj]

Hello,

Aha I think I've spotted the problem, the initialise calls the clear macro and this was looping while the X column was less then the display pixel width which was set to 256. I've changed the column variable from a byte to an unsigned int now and hopefully this should fix the issue for you.

gLCD_SSD1322_buffered.fcpx

(9.28 KiB) Downloaded 299 times

Let us know how you get on.

[Dutch]

sounds good! at least I was right for not passing the initialize state.

I did put the file in the components list and rebooted and compiled and tested on the display.
it unfortunately still does not pass because no display but also the led does not blink. The display clears though it remains black at startup. if I reset manually it shows the noise in the reset state and clears display when I have it run but no text on the display and the test led never blinks.
it does simulate fine in FC though..

you have some kind of processor you can run this on and see if the led at least blinks so it passes. I know you don't have the display but I test as long you have breath.. we should be close .

[Benj]

Hello,

Can you confirm if the code is now getting out of the initialise function. I've carefully gone through the init code and the drawcircle code and I can't spot any more causes for a lockup.

[Dutch]

I did some more testing. the display remains blank in all cases though.
if I compile and program board with all macro's on like in the file above it doesn't turn the led on. like it still does not pass. no led no mather if I move or remove all in the loop below.
because my display does not show anything I have to 'study' the behavior of the flow with the led..

what I did extra,
test: I disabled the initialisation - led does goes on now but steady on, nothing more (no blink or off time I can see)
test1: I did move the 'led on' output first in line now before the print Macro. led goes on for exact one second and 50mSec off (according scope), and on again one second again. (like the clear display macro resets all?)
test2: disabled all 3 macro's: led flashes one second on, one second off.

the programmer does put power on the board and direct after programming the led connected to B5 already shows this behavior. If you have any processor there with a led on a port (maybe a matrix block?) I think you will see the same behavior even without display connected.

if I wouldn't have had 40 euro or so already in these displays who does look promising for my goal I problably had given up already and found a different one . but now its getting interesting to see this go work!

hope this gave some insight, tell me what to do or test if needed.
I appreciate your time!
Angelo.

[Benj]

Hello,

Just tried a quick test here and it seemed to get all the way through the routines.

SSD1322Test.fcfx

(8.23 KiB) Downloaded 284 times

I'll have another look at your project to see if I can spot anything there.

Here is the component file I am using, just in case there has been a change I havent already shared.

gLCD_SSD1322_buffered.fcpx

(9.28 KiB) Downloaded 328 times

[Dutch]

i keep having the same results. il try to find another processor. the atmega328p i use did all the displays i had so far.
il try your fc to see if all 3 outputs go on.
maybe the arduino plugin for FC8 would accept the library and than it works but kinda costly way

[Dutch]

your test does only activate B0 in my unit too.

i have no luck yet in finding a different suitable processor yet. the ones i have miss the capacity for this to even compile. the search continues..

[Benj]

Hmm, ok I'll have a go on an Arduino for you and see how that gets on.

As a sanity check have you tried reducing the pixel width from 256 to 255 to see if that makes any difference?

[Dutch]

tested with 256 or 255 and no difference. just B0 goes on only.

i found a whole bunch of PIC processors we use in products from my work and i usually program or flash these with provided hex files... but or my FC has no licence for 16bit or the available Dram is not enough

either way if you could do an 'Arduino' setup in FC8 that would be awesome. not that i care that much for that platform but then we maybe can find the differences to 'fix' the macro.
the board i use is an Mini-pro 328 5v, if you want me to test something like led status or display working with 'hello world' text or so please send me an Hex file. i program with atmel studio and an ISPMK2 (to avoid that bootloader)

[Dutch]

Let me know if i can do or test anything.