SD Card on a AVR128DB28 Part

[ITDiscovery]

I'm trying to get SD Card working on the AVR128DB28 part, not on the primary port (PA4-PA7) using voltage dividers, which works perfectly. I want to be able to use the multi-voltage I/O pins PC0-PC3, so that I can drop the divider network. Seems like this is a no-brainer use case....yet it doesn't work. I am using the "Listfiles" example, and when using the PC0-3 I use SPI.swap(SPI1_SWAP_DEFAULT); as the first line in setup{}. I see SClk on PC02 and CS on PC03 no problem.

I ran this same example on one of Spence's AVR128DA64 boards, on both PA4-PA7 and on PC0-PC3 (using SPI.swap(1); ), which worked perfectly via the voltage divider network. I suppose that I can remove the jumper and add the 3.3V regulator, but I'm not sure what that would prove.

I feel like I am missing something. But I thought I have chased everything down. Maybe the answer is "it doesn't do that". Almost seems like I'm missing something like an interrupt isn't being attached or something.

I'm going with the voltage divider network for now via PA4-PA7, but using PC0-PC3 seems much cleaner. I do absolutely need the SD Card functionality, and I have plenty of I/O pins left over.

[mosqu-ito]

To use a second voltage on Port C you must both supply that voltage at chip pin 6 (complete with decoupling) and enable Multi-Voltage on the tools menu. If that doesn't help, maybe it's code issue?

[SpenceKonde]

I think what you're missing is what @mosqu-ito pointed out. The whole point of MVIO is that you supply a different voltage to the VDDIO2 pin - in this case 3.3v - and then you don't need to do any level shifting yourself - MVIO does it for you. I have AVR128DB64 boards assembled and ready to sell (with 5V Vdd reg and 3.3V VDDIO2 reg installed even - as well as versions with a software configurable fancypants regulator for VDDIO2, which lets you select 5v, 4v, 3.3, 3.1, 3.0, 2.5, or 1.8v (or 1.5 or 1.2 - but those are too low for MVIO to work). That regulator costs about as much as the AVR128DB64 itself, but my god it's specs are amazing. Minimum dropout is like... 0.1V or something? so you can get 5v on MVIO pins from a typical USB port as input, since these days those generally run a few tenths of a volt high for charging cellphones with crappy cables (max input voltage 6.5v though, and controlling it requires bringing pins close to it's Vin, so basically, you can only use it when running the AVR at 5v - I tied the enable line to PE6, and the two voltage select lines to PG6 and PG7.

The only thing keeping me from listing it is that i need to write up a product description and... do you have any idea how painful that is going to be for this? There are TWENTY solder bridge jumpers on the damned board! (2 for each crystal to let you isolate the pins from the FTDI header, then 3 more to let you reroute it to the USART0 alternate pins, 5 to route the power, 1 additional one to provide power if you're using an external clock instead of a crystal (so you can crank these bad boys up to 48 MHz) and the 6 standard ones - RPB, VUP, CTS-to, autoreset enable - and one to tie the ESP-01M's strapping pin to PC7 (connected to Serial1 alt pins, plus PC6 for CHPD, and if that bridge is closed, PC7 for BOOT0 - so you could have it start up the ESP in FW update mode, with the AVR configured to act as a passthrough serial adapter, and update the firmware that way. Note that I have never tested the esp functionality in any way shape or form, so I don't even know if that works. Obviously that only has hope of working if the regulator is 3.3v for VDDIO2. )

[ITDiscovery]

Yup...right on....the Business Card version I sent Spence (did you get it?, if not, I can send you another) has the voltage regulator on it, and that's failing. I also have Spence's AVR128DA64 which does work....although I haven't tried putting dropping a regulator on it (it has the spot for it, but it's jumped).

I should have added in the above post that the output on PC2 is the same clock I saw on PA6, and PC3 has the same CS but both are at 3.3V. Which eliminates the correct assumption @mosqu-ito made based on the incomplete data I posted. I'm pretty confident it's not an MVIO problem.

On Spence's product description, as I am an IT Architect, would you like some help creating that info? I am used to doing markdown, so that should work if you are directing to a GitHub project. I probably need a schematic at most and can get that cranked out.

[mosqu-ito]

Doesn't SPI1 live on those four pins normally without any remapping? And you say that port is operating at the desired voltage? So... you're simply having trouble moving from SPI0 to SPI1?

[ITDiscovery]

Yes, it seems so @mosqu-ito. I remapped SPI1 to SPI0 via SPI.swap(SPI1_SWAP_DEFAULT). I'm not seeing anyway to tell the SD library to use SPI1, so I don't see that as an option. Just for fun, and because I'm stubborn, I'll try SPI.pins() and see if that works. Otherwise, I'm reading from Spence above that this was a thing decided long ago, and it's just not going to work on this part. I'll also drop a voltage regulator on his AVR128DA64 and see if that works...betting it does.

[mosqu-ito]

I've not tried Our Great Benefactor's implementation of SPI yet, and I can see that you already know more about it than I do. But if I'm understanding him correctly, while there is only a single instance of SPI (not separate SPI0 and SPI1 instances) you nonetheless get to decide (via the swap routine which you appear to be using correctly) whether that single instance refers to hardware 0 on Port A, or hardware 1 on Port C. So I still don't understand why it's not working for you, particularly if it is working at SPI0_SWAP_DEFAULT. The only thing I can suggest is that you change only one variable at a time. That is, try moving everything that worked on Port A, including the voltage dividers, over to Port C, without using MVIO. Only if/when that works, try replacing the dividers with MVIO.

[ITDiscovery]

So my final answer is: "It does't work own the DB28 package for PC0-3." I'll be using a voltage divider off of PA4-7, which works, and drop the voltage regulator off of the project.

Settings:
Clock Speed: 24MHz
Mills Timer: TCB2 (also tried TCB0)
BOD Level: 1.9v
BOD Mode: Disabled
Save EEPROM: Retained
Reset Pin: Hardware Reset
Startup Time: 8mS
Flash Writing: Anywhere
MVIO: Enabled (there is a 3.3V regulator connected to VDDIO2)
attachInterupt: On all pins
printf(): Default, no floats
1xWire: Master or Slave (also tried Master and Slave)

Here's the code:
`
#include <SPI.h>
#include <SD.h>
File root;
void setup() {
Serial.begin(115200);
//SPI.swap(SPI1_SWAP_DEFAULT);
//SPI.swap(1) for AVR128DA64
SPI.pins(PIN_PC0, PIN_PC1, PIN_PC2);
Serial.print("Initializing SD card...");
if (!SD.begin(PIN_PC3)) {
Serial.println("initialization failed!");
while (1);
}
Serial.println("initialization done.");
root = SD.open("/");
printDirectory(root, 0);
Serial.println("done!");
}

void loop() {
// nothing happens after setup finishes.
}
void printDirectory(File dir, int numTabs) {
while (true) {
File entry = dir.openNextFile();
if (! entry) {
// no more files
break;
}
for (uint8_t i = 0; i < numTabs; i++) {
Serial.print('\t');
}
Serial.print(entry.name());
if (entry.isDirectory()) {
Serial.println("/");
printDirectory(entry, numTabs + 1);
} else {
// files have sizes, directories do not
Serial.print("\t\t");
Serial.println(entry.size(), DEC);
}
entry.close();
}
}`

[SpenceKonde]

That is not a good final answer! If it works on PA with a resistor divider, there isn't any good reason for it not to work on PC without the resistor divider - either there is a problem your connections, or a problem in the core which is not going to be fixed unless we can get a better idea of what's going wrong.

A scope trace (which will likely either show correct-looking traces, or I suspect, nothing at all -

A helpful "hardware sanity check" would be to run the chip from 3.3v (no need to change clock speed or anything - Dx-series is rated to run at their full 24 MHz maximum speed at anywhere between 1.8 and 5.5V!

So you should be able to use a 3.3V serial adapter, Vdd = VDDIO2 = 3.3V, and run from PA or PC just by moving 1x4 connector to different groups of pins and uncommenting SPI.swap(SPI1_SWAP_DEFAULT);

My guess is that that is going to continue to work only on PA, or you will discover the wiring mistake. Assuming no wiring error is found and it continues to fail, that just begs for a reproduction attempt by someone with a scope who can check what the pins are doing, if anything (and also, whether there's anything going on on any other pins).

Also, in this 3.3V/3.3V conviguration, verify (by reading PORTC.DIR - this sort of debugging is a great time to try out Serial.printHexLn() - I'd grab the values of SPI0.CTRLA and SPI1.CTRLA too. And hope that this points towards some clues.

(an aside about the whole voltage independence thing):
Dx-series runs the core at 1.x v from an internal on-chip regulator, which is apparently why the electrical specifications put a maximum on the slew rate (250V/ms, ie if it goes from 1.8v to 5v at your still in < 12.8 us (apparently, faster than that and the regulator can't keep up and overshoots, and you can damage the chip that way). Since (despite that stated maximum) it took only months after release for someone who was important enough to have some pull to trip over it, there was the thrash that there was in the beginning. (if you review the versions of the DA and DB datasheets, you see that the power supply guidelines initially recommended all 0.1uF caps. They then overcorrected and recommended all 1uF caps, which would provide poorer high frequency decoupling, before arriving at their current form: all 0.1's. plus 1uF minimum of board level decoupling in adverse circumstances). Personally I think anything under 4.7uF on any PCB (regardless of the chip) is poor designmanship, but nobody asked me). I usually go as high as I can get away with board level decoupling on USB-powered things (the standard imposes a rather low limit on the capacitance that a device is allowed to show the USB bus without inrush current limiting, but it's more than 4.7uF. I think either 10 or 22. )

That slew rate sounds crazy, but it's actually not hard to hit if you have just 2 0.1uF caps on the whole board, especially if the board is small, and it is suddenly connected to a very well decoupled supply. This can be done, apparently, by designing a board with a USB-connector made from the PCB directly into a laptop USB port, which is typically overdecoupled - putting just an inch or two of trace between the poor chip, cowering behind two scrawny 0.1uF capacitors, and a group of 100 and 220uF tants wielding baseball bats and crowbars and cable resistance or inductance to speak of. In microseconds the two 0.1uF caps have been flung skywards and hit the ceiling with a thud, and the tants have gotten a few good whacks in on the chip before the outmaneuvered, outmatched regulator even knows which way is up. And that's your power on sequence, everytime you plug it in.. now if instead you had a low quality USB cable going to a poorly made in china USB hub, things would go down differently... and while the startup might be safe for the chip, switching even a modest load could put non-trivial noise onto the USB power rail from the hub's perspective - since many cheap chinese hubs have practically no board level decoupling either (many of them also demonstrate astonishingly poor design practices. I've seen hubs with something like 0.2uF of decoupling on the whole hub, which caused every well-decoupled device plugged into the hub to reset the hub and trigger re enumeration (breaking all open serial ports, among other things) - and you could see the rosin from where some poor chinese worker was hand soldering that connection, a process they likely chose because their wave soldering wasn't catching the mechanical pins because they didn't have time to get hot enough to wet if they tried to just use wave soldering on it, and it was cheaper to halfass the board (which was single sided, and made from pressed rat-shit instead of FR4) and pay someone to solder the connectors down.

[ITDiscovery]

I’ll add scope shots and try running the chip at 3.3v. I do need other outputs at TTL level, so MVIO was the point. I’m 100% sure it’s not wiring or MVIO. I’d welcome someone else trying it with the AVR128DB28 package, and will send a board to anyone that wants to volunteer.

[mosqu-ito]

At first it wouldn't work for me on Port C either.
I did hack it into working. What I had to do was
to expose two normally private bytes in SPIClass
(yes, that means editing SPI.h) set them manually
and also set the direction of SS.

   
   SPI.swap(SPI1_SWAP_DEFAULT);

   SPI._uc_pinMOSI = PIN_PC0;
   SPI._uc_pinSCK  = PIN_PC2;
   pinMode(PIN_PC3, OUTPUT);   // SS
   
   SPI.begin();

[ITDiscovery]

Well...your skills are way better than mine. I tip my chapeau to you. I certainly am not capable of getting this across the finish line, but would be happy to do the paper work and any testing.

[mosqu-ito]

pins_arduino.h
Ooo, I taught myself how to use the github search.
I probably should have thought of that sooner. :D
At least I know where to look now.
But it's bedtime for this old man for today.

[mosqu-ito]

SK: I believe the SPI pins aren't being set correctly because of Issue 321 (already closed).

[mosqu-ito]

ITD: If you can find the variants/28pin version of the above-mentioned file you can probably patch it manually (lines 152, 153, & 153). You might still need the pinMode statement but you wouldn't need the hack. Maybe that would get you up and running.

Damn, wasn't I supposed to be going to bed?!

[SpenceKonde]

Github search is garbage.

I use Sublime text and find in files, ctrl + shift + f and it searches text file contents so fast it will make your head spin

[SpenceKonde]

Okay, this is the dumbest shit ever. do you know what the ONLY GODDAMNED TIME THE PINS REFERENCED THERE ARE EVER USED IS?

Guess...

IT's when they make a single stupid pinMode call to set them as outputs in begin. That library needs a flamethrower.

[ITDiscovery]

So this is a problem with the SD Card library? What's next step?

[mosqu-ito]

Let me wrap this up a little better for @ITDiscovery and/or anyone else trying to use SPI on Port C under the current release, because last night I was typing with my thumbs in bed. If you make a minor (three lines, one character each) repair to a single file buried in the core,
the ONLY other thing you'll need, to get running, is to add the line pinMode(PIN_PC3,OUTPUT) to your program. So that's:
(1) repair one core file, and (2) add one line to your program.

The tricky part is finding that one file. I use Linux. For me the file is located here:
~/.arduino15/packages/DxCore/hardware/magaavr/1.4.10/variants/28pin-standard/pins_arduino.h
If you use Windoze you'll have to search it up yourself (presumably Windoze has a search function).

On my Linux installation at least, no special privileges are required to edit the file, though stashing away a backup before you start is always a good idea.

You're looking for three lines (152, 153, 154) as described in closed issue #321. Although these have already been fixed by @ObviousInRetrospect for future release, they're not yet in the released version. Hence the need to go and patch it manually.

Here are the three WRONG lines:
//#define PIN_SPI1_MISO PIN_PC0
//#define PIN_SPI1_SCK PIN_PC1
//#define PIN_SPI1_MOSI PIN_PC2

You can confirm they're wrong by looking at page 18 of the datasheet.

Here's what they SHOULD be:
#define PIN_SPI1_MISO PIN_PC1
#define PIN_SPI1_SCK PIN_PC2
#define PIN_SPI1_MOSI PIN_PC0

Remember to save the file after the patch.

That's step (1) complete.

For step (2) just make sure you open SPI like this:
SPI.swap(SPI1_SWAP_DEFAULT);
pinMode(PIN_PC3, OUTPUT); // This is the special extra line, ie. step 2.
SPI.begin();

That should be that, no need to hack SPI.h (if you have, try to put it back how you found it) and no need to set the pins manually.

I'll be keen to know if that gets you going.

[mosqu-ito]

Addendum:

The above is all you need to get SPI working.
The SD library might pose an addition obstacle.

If you find yourself getting compilation errors from something called SD2PinMap.h
simply go into your arduino installation (for me that's ~/arduino-1.8.13) so
~/arduino-1.8.13/libraries/SD/src/utility
then find the file Sd2Card.h and comment out the line
#include "Sd2PinMap.h"

[ITDiscovery]

I’ll give that a go in the AM.

[ITDiscovery]

That took 10 mins to confirm that it works. On my MacOS the directory is:
/Users/ITDiscovery/Library/Arduino15/packages/DxCore/hardware/megaavr/1.4.10/variants/28pin-standard
I made a copy of pins_arduino.h just in case.

// SPI 1
#define SPI1_MUX                PORTMUX_SPI1_DEFAULT_gc
//#define PIN_SPI1_MISO          PIN_PC0
//#define PIN_SPI1_SCK            PIN_PC1
//#define PIN_SPI1_MOSI          PIN_PC2
#define PIN_SPI1_MISO.           PIN_PC1
#define PIN_SPI1_SCK              PIN_PC2
#define PIN_SPI1_MOSI           PIN_PC0
#define PIN_SPI1_SS               PIN_PC3

Here's the code as directed:

  pinMode(PIN_PC3,OUTPUT);
  SPI.swap(SPI1_SWAP_DEFAULT);

So the final answer now is: this bug has already been corrected (Issue 321), the fix is migrating it's way to release.