Commit Graph

7 Commits

Author SHA1 Message Date
Paul blue asus fafe706481 Another late commit from bunch of updates I made over a month ago..
Most progress was on jtag lua statemachine code.  From what I recall I
tested and verified most state change possibilities with logic analyzer.
So they should be fairly good.  Possible I didn't test all later ones,
or things are partly unfinished, but my best guess is they're good.
Appears was able to erase MachXO CPLD.  Added time delay for run test.
Did some basic testing for gameboy power switching circuit.

Also just got STM8S001 CIC programming working for discrete boards via
A0.  Pretty sure I broke EXP0 in the process for SNES boards..  So need
to go back and fix that I think due to new means of changing swim pin.
2018-02-13 14:36:43 -06:00
Paul blue asus 535b45be27 Committing working build that was used for flashing STM8 SNES v3.1
boards for SF2 builds.  Not necessarily the most clean, but it was
stable and worked well.

Need to get swim comms working on other board designs.
Need to come up with better swim activation with more exact timing.
Still need to implement swim comms on avr, hopefully that doesn't prove
to be too much of a PITA...  Not looking forward to that.  Can probably
only handle low speed, and faking pullup may not work as well without
time on it's side @ 16Mhz...
2017-12-20 09:28:01 -06:00
Paul Molloy 0dd8828744 Long over due commit...
-Updated STM devices to always run @ 48MHz
 Doesn't seem to cause any problems with SNES flashing couple thousand SF2
 boards have been flashed with this build without issues
-Added note to usb_operations.c as manf/prod ID can't be read if drivers
 aren't installed.  Caused issues for Todd as he hadn't installed drivers
 for new hardware.
-STM swim operations are working pretty well for SNES v2 and v3 boards
 Haven't even touched SWIM on AVR core yet...
 SWIM is pretty pin independent but only implemented on EXP0 so far
 Reads "ROTF" aren't bullet proof but they're pretty good.  Biggest
 room for improvement aside from adding a legit pullup would be to have
 an interrupt trigger the device header bit falling edge instead of the
 current polling method which has decent amount of jitter.
 Implementing interrupts would also probably allow for more easily
 supporing reads longer than a single byte...
2017-10-22 17:09:21 -05:00
Paul Molloy 5ceb148c85 Have SNES flashing and dumping working for all 3 kazzos on SNES v3.0p
prototype which has STM8 CIC driving flash /OE with inversion of SYS /RST.
STM8 CIC is running at 16Mhz, and doesn't actually function as CIC.  Still
need to come up with special way to signal to CIC that it's plugged into a
programmer and not a console.

Things aren't as fast as they could be, but they're good for now and
proved working on all kazzo versions.  Expecting decent speedup could be
aquired by optimizing the flash routine, not changing address unless
needed, or only changing low byte of address, etc.  Could also let the
host put the flash chip in unlock bypass mode and keep it there until done
with flashing.

Current speeds:
INL6: 42.2 KBps flashing, 92KBps dumping
stm adapter: 25.3 KBps flashing, 96KBps dumping
AVR kazzo: 18.0KBps flashing, 14.3KBps dumping

Was able to get the inl6 up to 59KBps flashing.  Which was 35sec total
flash time for 16mbit chip which has typical flash time of 22s plus
overhead.  This got slowed down when supporting stm adapter as checks for
buffer status were required from what I recall.  Also fixing flash polling
routine AVR found slowed things down.

Was able to get 140KBps dump time on inl6 with 16mbit SNES flash.  This
was slowed when supporting stm adapter which brought out issue with stm32
usb driver.  Locks up the device if the buffer isn't fully dumped prior to
calling.  Need to get driver to support sending NAKs until data is dumped.
Current fix for checking buffer status slows things down for all devices.

AVR brought out issue with SNES v3 design where we can't rely on flash
poll data to toggle between reads as /OE and /CE are stuck low.  Have to
toggle /RESET slowly to toggle /OE and ensure we don't move on to next
byte until previous is fully flashed.

STM32 found initial issue where /WR should be set low first to set
direction of data level shifter, then set /ROMSEL low to enable level
shifter output.  Not doing this caused bus conflicts between the two
causing flakey writes where not all bits were getting cleared.

lua scripts currently force SNES, need to add smart check that identifies
SNES flash board if vector data is 0xFFFF.  Also funky order where it
always erases after flashing as this was more convient for testing.

While this commit is far from ideal, it's stable and I've done my best to
not commit junk that will cause problems later.  Just make sure to always
verify dumping algo before assuming something is wrong with writes!
2017-08-24 13:41:08 -05:00
Paul Molloy dfeaf960ef commiting files as they were left a couple weeks ago..
Not 100% sure what all happened with this update.. :/

Tested and have all 3 recent kazzos flashing and dumping PRG-ROM and
CHR-ROM on NROM NES board.  Pretty sure I tested purple and green kazzos
too as I had left those on in pinport and seem to recall having them all
working when I tweeted 2 weeks ago..

Created new status_wait for buffers so can wait for them to finish
dumping/flashing before starting/ending operations.  That cleaned up
dump/flash code a fair amount.

On first tests today I had issues where setting flash operation would hang
and fail with both stm kazzos.  As I started to debug the issue it
disappeared, so IDK what that was all about..  I think there might be an
issue with my stm32 usb drivers..  Those were updated in this commit to
properly allow write "OUT" packets to be supported.

Planning to start tinkering with SNES in prep for the no save boards
arriving tomorrow!
2017-08-20 16:38:12 -05:00
Paul Molloy ea5f1d9842 Creation of pinport abstraction layer to make firmware more generic to the
underlying hardware/mcu.  Created avr_gpio.h to define AVR pin registers
in a struct fashion similar to what's common with ARM code.  Doing that
makes things much easier to abstract in pin macro 'functions'.

Added define to Makefiles that flags pinport_al.h which board is targetted
for build.

Tested and able to turn on/off and pull-up LED on all 3 builds.
2017-07-22 23:58:16 -05:00
Paul Molloy 3779afe88d Successfully building avr & stm core with one set of files.
Two different Makefiles, specify which with -f file flag:
make -f Make_avr clean program
make -f Make_stm clean program

made release dir to put released .hex firmware files
Need to make separate avr build folder
Need to make one master Makefile that calls one of the other makefiles as
instructed.

Currently device is recognized by PC but does nothing else other than
being recognized by app during connection process:

arm-none-eabi-size -t build_stm/inlretro_stm.elf
text    data     bss     dec     hex filename
1332       0      20    1352     548 build_stm/inlretro_stm.elf
1332       0      20    1352     548 (TOTALS)

avr-size avr_kazzo.elf
text    data     bss     dec     hex filename
1496       2      43    1541     605 avr_kazzo.elf
2017-07-22 17:03:23 -05:00