SSOP20 and MAX7219 and SPI SS on pin 9 and default setting of pin 8

[SuperUserNameMan]

Hello.

Given the specificity of the SSOP20 version which has external pins connected to several internal pins at once, I'm not sure if it's more about sharing experience than submitting an issue that has to be fixed but, because it might help solving other SPI related issues, I thought it might be useful to be shared. So here it is :

I was testing various MAX7219 libraries on MiniEVB SSOP20 and LQFP32.

MAX7219 needs SPI_MOSI, SPI_CLK and a CS pins.

Because the SSOP20 board has a limited number of pins, I wanted to use the SPI_SS pin as CS.

It worked with the LQFP32, but it never worked with the SSOP20.

According to the doc (which contains mistakes in the pin description tables BTW), on the SSOP20 SPI_SS is on PB1 aka pin 9. But this hardware pin is also electrically shared with PB0 aka pin 8.

Simply said : on SSOP20 pin 8 and pin 9 are connected together.

After several hours of despairs, I've found that to make the MAX7219 demo work on the SSOP20, pin 8 had to be set as an input ( pinMode(8,INPUT_PULLUP); or pinMode(8,INPUT); ).

So, I guess there must be an incompatibility issue between the default settings of these two pins 8 and 9 which make the use of SPI_SS (pin 9) impossible by default, unless you set pin 8 as an input in the setup().

Problem description :

• on SSOP20, default setting of pin 8 prevents the use of pin 9 as output which render SPI_SS unusable by default with some SPI related libraries.

Workaround :

• manually set pin 8 as input in the setup().

[LaZsolt]

Interesting. I have a board with SSOP20, and it's working without manually set pin 8 as input.

[SuperUserNameMan]

I have the same board than you.

It's really bizarre, because I tried again today and today it works directly without manually setting pin 8 as input.

Also, when I posted this issue, each time i was uploading the sketch to the board, Arduino was displaying many error messages : "could not connect to avrdude", "avrdude not responding" ...

And today, everything works just like a charm. I don't understand.

I'm closing this issue for now, and will reopen it or create a new one if required.

[SuperUserNameMan]

just for reference, the error message I was talking about are :

avrdude: stk500_recv(): programmer is not responding
avrdude: stk500_recv(): programmer is not responding
avr_read(): error reading address 0x0000
    read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2
avrdude: stk500_recv(): programmer is not responding

It was working just fine, and now it's starting doing that again without obvious reason (I only upload different sketchs without even touching the board).

I'm under Linux.

[SuperUserNameMan]

Not reopening this issue nor opening an new one for now. Just sharing some more experience.

I noticed a different but similar behavior with a MiniEVB LQF32 board.

After several sketch uploads, it randomly happens that avrdude displays the error messages above.

And sometimes, the board starts behaving strangely (like rebooting itself randomly).

So far, I've found that adding a delay(1000); at the beginning the setup() could prevent this problem from occurring.

I'm not yet 100% sure, but I think the board reboots too early or too fast before the upload is completed, and that some bits might end-up corrupted.

[LaZsolt]

The electrical parameters of LGT8Fx has not defined by Chinese. I think flash programming under 3 volts not reliable. So if someone using LGT8Fx on 3.3V, recommended bigger capacity on power lines.

[SuperUserNameMan]

The electrical parameters of LGT8Fx has not defined by Chinese. I think flash programming under 3 volts not reliable. So if someone using LGT8Fx on 3.3V, recommended bigger capacity on power lines.

My SSOP20 is 5V and was programmed at 5V. The LQFP32 is 3.3V and I programmed it both at 3.3V and 5V.

I tried different electrolytic capacitor in parallel to power line : 1 µF, 22 µF and 100 µF. Is it what you mean ?

Still happen randomly :

avrdude: stk500_paged_load(): (a) protocol error, expect=0x10, resp=0xd0
avrdude: stk500_cmd(): programmer is out of sync
avr_read(): error reading address 0x0000
    read operation not supported for memory "flash"
avrdude: failed to read all of flash memory, rc=-2
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0xa2
avrdude: stk500_disable(): protocol error, expect=0x14, resp=0xa2

[LaZsolt]

Voltage is okay, capacitor is okay. I read an Atmega8 uploading issue when it worked on internal oscillator. The oscillator frequency was a little different from factory defined, so upload was unsuccessful. Maybe your device internal oscillator's frequecy has a bigger error than 1%

[SuperUserNameMan]

Maybe your device internal oscillator's frequecy has a bigger error than 1%

Very possible.

This afternoon I was wondering about the effect of temperature over the frequency stability. It seems to me that it occurs more often when the board is running heavy-duty sketch, or after several uploads. I'll try to be more attentive to temperature to see if it is related.

If I remember correctly, the ATmega328 has an internal temperature sensor. Maybe the LGT8 also has one. Maybe it would give an indication of what causes the frequency instability. I'll look at it tomorrow.

[SuperUserNameMan]

Well, I just give up using serial adapter to upload sketches on my MiniEVB boards, because it's too unstable, some bytes of data end up corrupted, and it crashes randomly.

I could not find what was the cause. Most of the time the sketch starts running before avrdude has finished its work. I thought it could be related to the F_CPU change between the bootloader and the sketch, but I could not manage to verify this theory.

I'm using an Arduino Nano as ISP instead now. So far, so good.

[dbuezas]

Interesting, never happened to me. Could it be that the serial interface's clock (or the mcu's) are a bit off?

[SuperUserNameMan]

Interesting, never happened to me. Could it be that the serial interface's clock (or the mcu's) are a bit off?

I don't know .... Now, I've just found that the MiniEVB LQFP32 is more stable when compiled as LQFP48 ....

It's so unreliable that i don't know how to make sense of all of it.

Well, when the board is ok to run stable, the good news is that the LGT8F328P @ 32MHz is powerful enough to decode and play in real time (at a 12KHz soundrate) a 4 channels Protracker Module stored in flash using the PROGMEM direct accesstrick we discussed in an other discussion. :-)

[SuperUserNameMan]

Interesting, never happened to me. Could it be that the serial interface's clock (or the mcu's) are a bit off?

I've just found a CP210x usb-serial adapter in one of my drawers. Uploading sketch through serial port is stable now with this adapter.

Seems the culprit was the CH340E (aka BTE17-06) usb-serial adapter I used before. I updated the wiki with this experience.