RISKY MSX Rev2

[arkadiusz.makarenko]

I have started working on migration from WCH FAT32 badly implemented lib to FATFS.
This uncovered how badly I designed flash programming, code id badly coupled and now I need to spend quite a lot of time to sort this out.

So far I can read directories in long names, read data from USB, and started working on replacing old lib...

It will take me a while

[arkadiusz.makarenko]

I have done substantial progress with this.

Most stuff is implemented. I just need to add a way of navigating back across directories.

I was hoping to add EX-FAT support as well, but I almost run out of space on flash, I doubt I will be able to squeeze it.

[arkadiusz.makarenko]

I managed to enable FatFS, but build was too big by 800bytes to fit in the firmware. But I managed to kick out printf (used for debugging). This allowed me to kick out USART code and few other bits. Now I can fit ExFAT support in build!

Unfortunately it doesn't work.... I assume my diskio.c implementation is far too simplistic to support bigger USB drives.
I am planning to move dev for it to my Dev board (as I don't have printf so I can't have proper debugging statements on this project), and then I will port fixes back to RiskyMSX.

[PhilC]

All good progress still

[arkadiusz.makarenko]

.... And I be it working and squeezed into firmware.
sort of.

So Issue is that I had was much simpler than I thought..USB itself told me what is wrong,.I just never looked at what this error means.

Issue was that I didn't give enough time for device to prepare data. It was sending me info to wait I just didn't listen.

Because my implementation was (still is) crude as hell it was expecting data straight away, and solution was just to add 3ms delay.
Now it is checking and waiting on repeating when needed.
Still I need to add arbitrary wait at the end for some reason. I assume next request is done too quickly, so I need to review and add similar approach in all other usb requests types.

Good progress

[ahmsx]

Hi,

Just registered to the forum to follow up on the riskymsx cartridge developments.

While reviewing the BoM of rev2.1 to cleanup some minor inconsistencies I found between the CSV BoM and the schematic/pcb, some doubts arised again about specific components.

The doubts start with C3 mainly: that is one of the input capacitors to the LM1117 voltage regulator according to the schematic. It's value/footprint is 100nF/0603 on the CSV BoM but 10uF/0603 on the schematic/pcb kicad files. Also looking at the schematic there is another input capacitor C1 of 100nF/1206 (same value/footprint in CSV BoM and schematic/pcb). Looking at the PCB, C1 is located close to the LM1117 and C3 is located near the F2 fuse. And along the way between those two capacitors there's C7 of 100nF/0603 according to the CSV BoM and 100nF/1206 according to the PCB.
Looking at the LM1117 datasheet, and taking into account that those capacitors are providing capacitance to VBUS too, I wonder what would be the proper values/footprints for those three capacitors (even if the cart probably works ok irrespective if you follow CSV BoM values or schematic values).
I built my riskymsx rev2.1 cart with C3=10uF (as in the schematic/pcb), C1=100nF and C7=100nF, and works fine.
It seems that a uF order would be better for the input capacitor of the LM1117 and for providing capacitance for VBUS according to the USB 2.0 specs.

Then there's the output capacitor C13 which is 1uF/1206 (same value/footprint on the CSV BoM and schematic/pcb). According to the LM1117 datasheet that should be 10uF tantalum, or capacitor with equivalent ESR, to maintain regulator stability (again, it probably works fine with 1uF with the specific use case in the riskymsx cart, just trying to understand/clarify the BoM).

9.2.2.1.3 Output Capacitor
The output capacitor is critical in maintaining regulator stability, and must meet the required conditions for both
minimum amount of capacitance and equivalent series resistance (ESR). The minimum output capacitance
required by the LM1117 is 10 μF, if a tantalum capacitor is used. Any increase of the output capacitance will
merely improve the loop stability and transient response. The ESR of the output capacitor should range between
0.3 Ω to 22 Ω.

Thanks again!

[terriblefire]

The caps on the regulator don't really matter in my experience. I've used 10uF or 100nF interchangeably. if the BOM was used for assembly and it works use that value. Often i change values for assembly. i.e ignore schematics

EDIT: For me the schematic is just something i use to produce the PCB, once that's done i don't care about the schematic. I might even change values on the schematic on purpose to trigger people with OCD. Yes i'm evil

[arkadiusz.makarenko]

@ahmsx
I think using higher values might be good idea, so instead of 100nF for C1 use 1uF, and C13 use 10uF good quality like 50V multilayer cap instead.
I don't like tantalum caps because how they like to fail, so I use ceramic if I can get away with it.
CH32V303 chip is really resilient and definitely is designed in a way to operate in much worse conditions than we have here, eg. battery powered, portable devices etc. so it should be able to take much more abuse and still work relatively stable.

[terriblefire]

Yes I have empirically shown than LM1117s do not need tantalum caps. They work fine without it. Datasheets, despite what people think, are often wrong and frequently works of fiction

[arkadiusz.makarenko]

I have released beta firmware with FATFS lib that includes full Long File Names and ExFAT support.
https://github.com/arkadiuszmakarenko/R ... 3.0.0-beta