Commit Graph

5 Commits

Author SHA1 Message Date
Paul Black ASUS win7 223007187b Have BNROM, and action53 working in PLCC and TSSOP.
Also added swim reading of stack bottom for CICOp signature.
Starting to add scripts for different mappers.
Need to clean things up quite a bit as everything was a bit of a hack just
so I could start building lizards and A53.
Need to add back NROM, and add UNROM as well.
Need to have program find bank table for itself both in the program and in
a cartridge.
Having problems with SWIM on new discrete NES boards for some reason.
Some boards are flakey and I march right in and start writting to config
bytes which will brick the device if communications are failing (and
there's no reset pin...)  as is with the stm8s001
2018-03-17 21:56:24 -05:00
Paul blue asus 3c359ac5ca Double and long overdue commit..
Various changes to STM8 SWIM code to make more versatile allowing SWIM
pin to be located effectively on any STM32 GPIO pin.  Still haven't
touched an AVR implementation, but made place holders so it can compile
for AVR at least.  These SWIM changes aren't heavily tested, mostly just
made sure could flash SOIC-8 STM8 CIC via CIC CLK.

Beginings of JTAG code to configure CPLDs.  Currently only tested state
change and scan out reading MachXO-256, 4032/64v, & XC9572/36XL CPLDs
Tested and working on inlretro6 v1.0p, stm adapter, & avr kazzos.
Older devices with flipflops will apply 5v signals to JTAG pins but time
is mostly minimized by keeping signals defaulted low unless actively
changing states or scanning data.

Still need to verify scan in working, probably move TDI/TDO long strings
to buffers instead of 32byte PBJE data array.  Also need smarter PBJE
host code to keep track of current state and come up with PBJE register
values without hard coding them..

But things are working fairly well so far with SWIM & JTAG
implementations.  Had some issues where I thought jtag pin toggling was
getting optimized out, but I must have simply had the logic analyzer
speed set too low and was missing pin changes that can be as quick as
40nsec with space optimized code.  Current inl6 code is ~4400Bytes,
without optimization it's nearly 50% larger at ~6550Bytes..!
Optimizations seem fine in testing and with logic analyzer running at
50Mhz which is good because the GPIO registers are set as volatile so
they better not be getting optimized away!
2018-01-01 23:32:09 -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 235e1649f1 Successfully flashing STM8 CIC via SWIM!
currently flashes binary file to flash and sets option byte for TIM1
TODO program ROP byte!
next up to control flash /OE pin via SWIM instead of EXP0
2017-10-22 22:57:03 -05: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