Fix for 3.3V instability #626
Replies: 4 comments 7 replies
-
|
Out of curiosity, how long does it take to dump a N64 game with 8MHz? Does it have a huge impact or is the SD card still the limiting factor? |
Beta Was this translation helpful? Give feedback.
-
|
I just tested "Star Wars Episode 1 - Racer" - it took 4 minutes to copy the ROM, then another 7 minutes to complete the CRC, so 11 minutes total. The first time that I did it, I thought that the system had crashed because the CRC took such a long time, but eventually it gets there... and the ROM works, so I'm happy :) |
Beta Was this translation helpful? Give feedback.
-
|
When I had stability issues I noticed 2 things:
You could check that and see if it helps. Where did you get your Arduino/which one did you get? I have keyestudio's version. When I started looking into automatic/programmatic voltage switching I originally planned to always run the Arduino at 5V and use logic translators to step down to 3.3V. While I still want to do that it will add at least $10 to the cost and require much more SMD soldering. It also would require a new main PCB. So I decided instead to replace the voltage select switch. If starting in 5V and switching to 3.3V afterward resolves your issue you could use the voltage select module that just got added as it starts the Arduino in 5V mode and switches to 3.3V after boot. |
Beta Was this translation helpful? Give feedback.
-
|
I tried starting with 5V then switching to 3V, but although the OLED screen showed the first menu, the display became corrupted when I then progressed through the menu items. I also tried the "Serial Monitor" firmware, which allowed me to navigate the menus and try dumping the ROM, but the system always froze up when I started the "Read ROM" operation. I've visually inspected the solder joints and they look OK. To be honest, I don't much fancy resoldering all of the joints - once was enough! I got the Mega 2560 clone from a seller on ebay - visually it looks identical to the one in the AliExpress listing in the build guide and it has the appearance of a no-brand chinese knock-off (I wish that I had seen the Keyestudio version - it's the same price as mine was and looks like better build quality). My guess is that there could be something of a silicone lottery when it comes to undervolting/overclocking the ATMEGA2560s - probably these clone boards use ATMEGA2560 chips that are the absolute runt-of-the-litter, so-to-speak. Possibly even chips that Atmel/Microchip threw away because they failed to meet their minimum tolerances. That's just speculation on my part, though. I thought about getting an Adafruit Grand Central to use for 3.3V operations - it's a drop-in replacement for the Arduino Mega, but it runs with 3.3V logic. However, reducing the clock speed seems to be working with my build, so I'm happy-enough with that at the moment. The automatic voltage select module is a very good idea BTW - I have accidentally had the system set to 5V when trying to read a 3.3V cartridge, so any way of avoiding that kind of slip-up is well-worth it! Automatic voltage-select + logic-level shifting of the data lines would be the best solution, but as you say, that's a lot of work. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, logic-level shifting is best. I'm doing that in my single-board redesign. It combines all the modules except for the LCD into a single board. ATmega, clock gen, six-slot, all of it. If you've got it stable on 3.3V now you can try the voltage select module. I don't know how well it'd work on HW3, I put that it was only for HW5 because I don't have the others to test them, so you'd need to adjust the code. I tested it with no carts inserted at first by just connecting a multimeter to VCC and ground and checking that it changed when I selected the carts. It defaults to 3.3V so it's "safe". |
Beta Was this translation helpful? Give feedback.
-
|
Another aspect of build quality of less-than-ideal arduino boards: I found out the micro-B USB port on mine did not have any solder on its strain relief pads. All that was keeping it in place were the actual pins. At least this was easy to fix, and I recommend checking if the port is actually correctly soldered before it gets ripped off the board. |
Beta Was this translation helpful? Give feedback.
-
|
I think it was just low quality ATmegas that got produced during the global chip shortage. The project is already 8 years old and this is the first time we had widespread issues with 3.3V. The datasheet specifies min. 4.5V, max. 85°C, for 16MHz. We are not running the ATmega that hot, so naturally there is some wiggle room with the voltage as chips get more efficient when running colder. I mean it's not a medical device just a cartridge reader. As for the starting up issue at 3.3V, you probably just need to set the brown-out fuse bit to a lower voltage or just disable it altogether. The automatic voltage switch will fix one related issue though, the power/voltage switches build up a layer of oxidation with time that can be removed again by re-soldering it. You can actually measure it with an multimeter, the resistance gets higher, like from ~0.1Ohm to 1 or 2 Ohm after some time and then gets down to ~0.1Ohm after re-soldering again. Clocking the ATmega at 8MHz is not an option as the dumping times show. I did a mock-up with MCP27S17 extenders and a RPi Pico instead of the ATmega but I didn't like the added complexity, still nice though:
|
Beta Was this translation helpful? Give feedback.
-
|
I was thinking about the pico or CM4, but yeah pico would need extenders and CM4 is basically impossible to find. I was looking at doing a single-board design with the Arduino+clockgen integrated into the board so you could order the board nearly fully assembled from JLCPCB. It makes it easier to accept the $25 flat assembly fee then, but they have a minimum of 2 assembled boards and you'd also still have to solder on all the slots. Have you considered moving the program logic to the computer and having the computer just tell the Arduino what to do via serial? That'd save $10 or so for the LCD/SD module. |
Beta Was this translation helpful? Give feedback.
-
|
Did you ever revisit the STM32 idea? |
Beta Was this translation helpful? Give feedback.
-
@kamalawala I've been toying around with an STM32 (specifically an STM32MP157 via a STM32MP157D-DK1 Discovery Kit) and RP2040 (via a Pi Pico). They both seem viable, the RP2040 is cheaper, but the STM32 is more powerful. The STM32 is tempting, especially now with the Arduino GIGA existing, though it's of a lower spec than the STM32 I'm working with now. I probably should make a thread about that, actually. Hardware-wise, the biggest issue with both of them, the RP2040 and STM32, is that neither of them is 5V tolerant, so logic converters are needed. I've made some prototyping boards for a few chips as I have some ideas, but nothing concrete yet as I haven't ordered them (ran out of hobby budget, lol). But overall, the blocker will end up being that any shift off of AVRs won't be compatible with the current codebase. That's one of the reasons I've been trying to clean up the code; the cleaner it is, the easier it will be to port to another architecture. |
Beta Was this translation helpful? Give feedback.
-
|
I added dynamic clock scaling based on the system that was selected in #752 You need to enable it in the config, it's disabled by default. Since most people don't need it, and it makes dumping N64 games painfully slow, I didn't want to enable it by default. The upside of this vs. the proposed solution is that it only clocks down to 8MHz when dumping a 3.3V game. This way, you don't need to dump all games more slowly. Hopefully, that fixes it for the people with issues. If anyone still has issues let me know if it helps :3 |
Beta Was this translation helpful? Give feedback.
-
TLDR: setting the ATMEGA2560 clock frequency to 8MHz appears to fix stability issues in 3.3V mode.
I have built the v3 hardware Cart Reader and programmed it with the v9.5 firmware. It worked fine in 5V mode, but 3.3V mode did not work properly (OLED screen was blank or corrupted, ROM dumps would not complete). The default system clock frequency for the Arduino Mega 2560 is 16MHz and if you check the ATMEGA2560 data sheet section 31.2 (https://ww1.microchip.com/downloads/aemDocuments/documents/OTH/ProductDocuments/DataSheets/ATmega640-1280-1281-2560-2561-Datasheet-DS40002211A.pdf) it shows that a Vcc range between 4.5V - 5.5V is "safe" when running with a 16MHz clock. It also shows that a Vcc range between 2.7V - 5.5V is "safe" when running with an 8MHz clock. So I tried using the 8MHz clock, and this seemed to fix my issues in 3.3V mode.
You can set the system clock prescaler so that the cpu clock frequency is 8MHz by adding the following code at the beginning of the "void setup()" function in "Cart_Reader.ino":
noInterrupts();CLKPR = _BV(CLKPCE); // enable change of the clock prescalerCLKPR = _BV(CLKPS0); // divide frequency by 2interrupts();Now the ATMEGA2560 will run at 8MHz. However, this means that all timing funtionality that counts clocks will take twice as long as before. This can be fixed by setting the f_cpu value for the Arduino Mega 2560 in the "V9.5_Portable/Arduino IDE Portable/hardware/arduino/avr/boards.txt" file to 8000000L instead of its default 16000000L - i.e. change line 211 to
mega.build.f_cpu=8000000L(Probably a "better" solution would be to define a new board in boards.txt (called somthing like "Cart Reader 2560"), copying all of the Arduino Mega 2560 settings and just changing the f_cpu for that new board definition, and leaving the Arduino Mega 2560 definition alone.)
I have tested the 8MHz clock for dumping Gameboy ROMs in 5V mode and N64 ROMs in 3.3V mode and it seems to work. I have not been able to test any other functionality.
Hopefully this will help anyone that is having stability issues in 3.3V mode.
Beta Was this translation helpful? Give feedback.
All reactions