It is currently Fri Dec 15, 2017 4:52 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 9 posts ] 
Author Message
PostPosted: Thu Nov 23, 2017 3:23 pm 
Offline

Joined: Thu Nov 23, 2017 2:50 pm
Posts: 4
Some context first: I am busy attempting to add SPC7110 support to the sd2snes firmware. I have gotten to the point where I have everything but the Epson RTC implemented. I also had to alter the MCU firmware to load the SPC7110 FPGA bitstream file, which I placed on the SD card alongside my custom firmware.img. It boots normal games just fine, but any (non-RTC) SPC7110 software fails to load. It doesn't even crash. It just hangs at "Loading..." forever.

I would like to be able to debug the MCU firmware somehow, so I can see which step is actually hanging the MCU. I noticed the sd2snes cart has a mini-B USB port present, so I plugged a computer into it, but nothing seems to appear on the port. Is there something I am missing? I would assume it would provide at least a serial adapter interface for reading all the printf messages.

For the record, I have pushed all my code onto this branch of my fork. The only other change I made to the MCU firmware was building it with ARM's own GCC toolchain, instead of the one recommended in the readme, since I wasn't able to get that toolchain to build on Windows or Ubuntu. I'm under the assumption that if there is some kind of serial debug functionality in the MCU firmware, that it isn't particular to the snowcat.de provided toolchain.


Top
 Profile  
 
PostPosted: Thu Nov 23, 2017 4:18 pm 
Offline

Joined: Mon Jul 02, 2012 7:46 am
Posts: 760
I'm pretty sure ikari has said that the SD2SNES's built-in RTC is actually based on the SPC7110, so you can probably use that instead of reinventing the wheel...


Top
 Profile  
 
PostPosted: Thu Nov 23, 2017 6:22 pm 
Offline

Joined: Thu Nov 23, 2017 2:50 pm
Posts: 4
Well, that'll help out a bunch once I get the MCU to actually load the new FPGA config...


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 10:40 am 
Offline

Joined: Thu Feb 07, 2013 1:15 am
Posts: 96
Location: Sweden
Have you tried to get in touch with ikari_01 about it? I’m sure he’d be happy to help with getting this addition to a releasable state. He’s usually around in #snesdev on IRCNet.


Top
 Profile  
 
PostPosted: Fri Nov 24, 2017 3:40 pm 
Offline

Joined: Sat Jun 24, 2017 10:22 am
Posts: 6
There's a 14-pin bus on the side of the sd2snes (next to the battery). 3 of those pins are the UART output where the firmware printf output goes to. You can solder in a header and get a 3-wire UART to USB cable to view the output in a serial terminal. 3-GND, 6-RX, 7-TX. Hopefully the attached picture helps. It probably won't be a problem for what you are doing, but the printf code is not reentrant which can cause issues in the interrupt handlers.

The USB port isn't clocked/enabled in the current 0.1.7x firmware.


Attachments:
sd2snes_uart_connections.jpg
sd2snes_uart_connections.jpg [ 198.61 KiB | Viewed 388 times ]
Top
 Profile  
 
PostPosted: Sat Nov 25, 2017 2:24 pm 
Offline

Joined: Thu Nov 23, 2017 2:50 pm
Posts: 4
Thanks a ton redguy, I'll try those UART pins next time I get a chance with a soldering iron. Wonder why the USB port is even there...


Top
 Profile  
 
PostPosted: Sat Nov 25, 2017 3:01 pm 
Offline

Joined: Sat Jun 24, 2017 10:22 am
Posts: 6
I recall seeing something about loading the firmware over JTAG using USB when reading through the source. Maybe that's how it was done before the bootloader supported it from the SD card.

There is a custom firmware that enables the USB port and adds some features:
viewtopic.php?f=12&t=16720


Top
 Profile  
 
PostPosted: Sun Dec 03, 2017 9:31 pm 
Offline

Joined: Thu Nov 23, 2017 2:50 pm
Posts: 4
So, I haven't got a chance to find a UART cable yet (I'm worried about getting a fake one and then it getting bricked by FTDI) but I did notice the MCU firmware actually does use the LEDs as a 3-bit error output when FPGA errors occur. Specifically, it's the LED_PANIC_FPGA_DEAD pattern, which fires if the FPGA fails to return the correct test token over the SPI bus. I audited all my changes to main.v and it turns out I was a *little* more overzealous when getting rid of bsx/dsp and accidentally removed some of the cheat outputs, which I guess broke SPI? Adding them back in means that I'm now greeted with a failing SPC7110 test ROM when I load an SPC game (everything reads NG), but that's better than the MCU not starting the game at all.


Top
 Profile  
 
PostPosted: Mon Dec 04, 2017 9:27 pm 
Offline

Joined: Sat Jun 24, 2017 10:22 am
Posts: 6
The cheat module and associated $200B snescmd_buf handle some features for the menu like fades and reset related things. The firmware fully unlocks the $2A00-$2BFF block for the menu and then it gets locked (open bus to SNES) except for certain events like NMI/IRQ hook execution. The hook code attempts to read the controller 1 buttons (usually too early with AJR enabled) and performs the WRAM cheat writes along with button checks for resets+other commands.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: Bing [Bot] and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group