New USB dev cart - currently debugging
Written by cafealpha 4 comments
USB dev carts during different populating states
"This isn't even my final form"
I could populate 3 boards ... third one is not on the picture, while a couple of capacitors is missing on second one, but this is a matter of 5 minutes to solder.
After that, time was missing, and what's more problematic, ICs were missing too >_<
I soldered my last flash chips (on the right side of the cart), as well as my last USB chips and connectors (top left side of the cart) ... and my last 100nF decoupling capacitor (everywhere near all ICs) too ... it's a shame about the capacitors because they cost absolutely nothing and they are required everywhere in the cart.
So what's the plan from now ? I'm currently improving USB dev cart firmware, and plan to sell the completed cartridge on the bottom right corner of the picture when firmware will be ready for release.
From that money, I will buy a new stock of ICs to populate other PCBs
Why not buying ICs now ? Simply because I don't have enough budget for that, and also because buying ICs in few quantities is too much expensive : IC price decrease with quantity, and shipping fees are free when more than of USD100 of ICs are purchased.
So let's come the interesting part : firmware, which means software !
Last month I had enough about PCB design with Kicad, so that was good to get back with my Saturn and USB connect it to my laptop
My Saturn development environment : no expensive vintage development kit,
only a modchipped Saturn, USB dev cart and 7 years old laptop are enough.
So of course I lost a lot of time with stupid software troubles.
Here is a list of the troubles. I hope that writing them here will prevent me from repeating the same mistakes in the future.
1) Data alignment problem : one structure is 1 byte packed, and some long word was put a non 4 multiple offset in this structure. It is usually easy to spot, but ...
- It doesn't cause problem under yabause (? not verified, please tell me if I'm wrong), so this problem was unnoticed until I test it under real hardware.
- It happened during program initialization, before USB transfer would allow me to easily find why my Saturn freezes.
- I was sleepy at this time
2) Adding byte size to unsigned long* pointer ... it resulted in pointer set 4 times farther than expected ... really stupid bug
Oh, and in the same fashion, a similar bug in Action Replay flasher utility prevented from writing more than half of flash memory size ... it's good that I could fix this bug before anybody notice it
3) Saturn freezes when reading flash vendor/device IDs.
As usual, when Saturn freezes, it is during program startup, when USB can't be used for debug ^^;
This problem was the most interesting one : some parts of the firmware runs directly from Flash ROM, and it seems that reading flash vendor/device IDs makes whole flash returning theses IDs, resulting in invalid instruction from CPU ... this is just a guess, correct me if I'm wrong.
This problem was corrected in a very Q&D way : return 0xBFBF/0xB7B7 in FlashGetVendorID/FlashGetDeviceID functions
I have a better idea to fix this, but it requires to modify cartridge flasher utility ... I made enough flasher utility stuff recently (I'm enough in fixing compatibility issues with Action Replay old flash chips !), so I will fix this later.
After that, time was missing, and what's more problematic, ICs were missing too >_<
I soldered my last flash chips (on the right side of the cart), as well as my last USB chips and connectors (top left side of the cart) ... and my last 100nF decoupling capacitor (everywhere near all ICs) too ... it's a shame about the capacitors because they cost absolutely nothing and they are required everywhere in the cart.
So what's the plan from now ? I'm currently improving USB dev cart firmware, and plan to sell the completed cartridge on the bottom right corner of the picture when firmware will be ready for release.
From that money, I will buy a new stock of ICs to populate other PCBs
Why not buying ICs now ? Simply because I don't have enough budget for that, and also because buying ICs in few quantities is too much expensive : IC price decrease with quantity, and shipping fees are free when more than of USD100 of ICs are purchased.
So let's come the interesting part : firmware, which means software !
Last month I had enough about PCB design with Kicad, so that was good to get back with my Saturn and USB connect it to my laptop
My Saturn development environment : no expensive vintage development kit,
only a modchipped Saturn, USB dev cart and 7 years old laptop are enough.
So of course I lost a lot of time with stupid software troubles.
Here is a list of the troubles. I hope that writing them here will prevent me from repeating the same mistakes in the future.
1) Data alignment problem : one structure is 1 byte packed, and some long word was put a non 4 multiple offset in this structure. It is usually easy to spot, but ...
- It doesn't cause problem under yabause (? not verified, please tell me if I'm wrong), so this problem was unnoticed until I test it under real hardware.
- It happened during program initialization, before USB transfer would allow me to easily find why my Saturn freezes.
- I was sleepy at this time
2) Adding byte size to unsigned long* pointer ... it resulted in pointer set 4 times farther than expected ... really stupid bug
Oh, and in the same fashion, a similar bug in Action Replay flasher utility prevented from writing more than half of flash memory size ... it's good that I could fix this bug before anybody notice it
3) Saturn freezes when reading flash vendor/device IDs.
As usual, when Saturn freezes, it is during program startup, when USB can't be used for debug ^^;
This problem was the most interesting one : some parts of the firmware runs directly from Flash ROM, and it seems that reading flash vendor/device IDs makes whole flash returning theses IDs, resulting in invalid instruction from CPU ... this is just a guess, correct me if I'm wrong.
This problem was corrected in a very Q&D way : return 0xBFBF/0xB7B7 in FlashGetVendorID/FlashGetDeviceID functions
I have a better idea to fix this, but it requires to modify cartridge flasher utility ... I made enough flasher utility stuff recently (I'm enough in fixing compatibility issues with Action Replay old flash chips !), so I will fix this later.