dcwbrown
Add eeprom dump, editing, and possibly load commands.
Hi Excellent project. Glad to see someone conversant with SID! I'm new to this so not sure how to upload anything. I've modded the Global for a new cpu Attiny2313 the DWDR is not listed on the datasheet but by trial and error its 01fh. all the commands work but I agree eeprom commands are missing if you beat me to it (which I suspect you will) upload the mods and i'll try them out for you. On my list is modding the sram too.
Thanks!
Use the 'l' (load) command to upload either binary files or .elf's. If the .elf has symbols they'll be used by the 'u' (unassemble) command to annotate the disassembly.
I'm currently working on using a digispark as an alternative to an FT232, and adding atmega 48/88/168/368 support (which is great for the very cheap clone 'arduino pro mini' boards.)
I'll look at adding eeprom support, and commands for writing to sram/flash/eeprom.
@dcwbrown "digispark as an alternative to an FT232" :D good news. Attiny as Dwire debugger :) I am thinking an USBASP ISP programer with Dwire debugger functions.
I am implementing the debug wire support by extending the littlewire firmware (thanks to help from @plasticassius), so the digispark provides both usbtiny support for avrdude, and debugwire support for dwdebug.
Well, thanks for the thanks, but I haven't done anything with this besides a few lines worth of discussion... Cheers,
Hi David
E2 read/write working on 2313 a little crude but reliable I found the same problem others had with the speed and I see in your code you use the middle of the range of values but I found using a perl script (copied the idea from the forum ) that its more reliable with a lower speed (which make good sense for a s/w uart) So putting on the command line the speed is more reliable for me.
Ian
Sorry David if I knew how to upload the files I've modded I would but ... I'll look at the sram later and let you know
Hi David Done Sram read/write io register read/write e2 read/write need to do more checking and tidying up Not very tidy I've used your excellent routines as a basis and modified for the relevant addresses
Sounds great. May I see what you have changed? According to the edit box I'm typing into now, you can add files to your post. Re speed - why do you say it is more reliable with a lower speed for a s/w uart? As far as I can see, the middle speed should be the one for which the FT232 is best in sync for all bits transmitted by the device.
Hi David
I've attached a zip file of all the sources. Having written many s/w uarts over the years (I'm an old style assembler programmer of > 40 years and have written many monitors for development systems {hence the familiarity with SID} one without the use of any ram just the registers . Now that's a challenge) so I know pretty well the problems of s/w uarts especially ones that rely on a lack of xstal. Hardware uarts sample usually at 16 x the bit rate.A software uart samples usually 1 or 2 . Given that the uart on the pc is xstal controlled the uart on the avr can only be a s/w one as there is no xstal just a rc oscillator. (This may use the internal uart but I doubt it as it would be devilishly difficult to multiplex when you are using the ICE facility ) So based on the fact that the receiving uart is a s/w one the slower you can run it at the better the chances of reading reliably (imagine a bit rate of 1 bit/sec then 2 % tolerance at 8Mhz would disappear and it would be ultra reliable. Viz low frequency comms on submarines)
The odd ball csv's are dumps of the actual comms via an avr ice (debug wire) as sampled by a logic analyser. That's how I could work out what was wrong in the original documentation (the atmega32 doesn't support debugwire according to the datasheet just a jtag interface so I simply sampled the AVR studio talking to the debugwire.
If you need any more info on what I've done just ask
As I said I've taken liberties with your code and not made it generic in some parts
Whilst I think on
When using the I function for the i/o it require the io address base 0 but displays it at the actual addrres e.g. address 0x13h gpio1 shows as 0x33 its actual address in the memory map when displaying. There are other oddities like if you do an I
It's dead neat altering leds without the cpu running writing to the pin port does toggle as it should (I debated whether it may need to be running to do this sort of thing as in theory the clock is stopped I read somewhere {not convinced cos it does do things that require a clock})
Thanks for the zip, that looks good. I'm currently working mostly locally in an updated version of dwdebug in my little-debug-wire repository, and will integrate many of your changes, if that's ok.
Do you feel strongly about having separate commands using offsets into the io reg and sram areas? I had come to the conclusion that it is simpler to treat everything as a data memory address the same as as most processor instructions do. I decided that separate commands adds too many special cases.
Re Atmega32 - do I understand right: you found that the Atmega32 does support debugwire?
Re serial speed - I'm not sure we're talking about the same thing. Yes, using a slower device speed would give more reliability, but the code you see that says 'choosing middle speed' is not trying different device speeds. My connection code is working out what speed the device has already been configured at by sending repeated breaks each with the FT232 configured at a different speed and seeing what the FT232 makes of the returned 0x55. By starting with the FT232 configured fast and stepping down, the 0x55 response from the device is initially seen as long blocks of 0's or 1's and after a while the received byte has shorter and shorter runs of 0's and 1's, until we find a speed at which we see 01010101. Then we need to bracket the range of speeds that return 01010101 and choose the middle one to get the last bit sampled as well as the first. (It's very Heath Robinson/Rube Goldberg.)
Thanks!
Incorporate as you wish.
I agree its simpler to treat it as a linear address space but most non programmers tend to see separate address spaces for i/o and memory, but I personally can work with anything in just about any format (e.g. Z80/8080 V 6800/8K). I have not tried to change the way you wrote the s/w just chose the easiest route to achieve what I wanted (selfish yes).
No the latest datasheet from Atmel/Micro states the atmega 32 does NOT support debugwire (could be I was just tired when I read it and I may have missed the crucial bit saying it supported debugwire. So I'm guessing jtag uses a similar approach to debugging and that's how he got the dumps.)
If jtag uses the i2c or spi or any synchronos serial comms then the comms interface would inherently be very reliable. I've never looked as I've never used a jtag interface ICE. My predominant ICE uses are with INTELLEC ICE (it used to take 3 hours to load off paper tape so reloads did not happen often and patches were numerous. Bonded out chips were (are ) very very expensive hence the modern method of integrating the ice type facilities onto the cpu direct.
I saw what you were doing with the speed calculations for the connect whether it was a ft chip is something that you are far more conversant with than me but fundementaly it does not change the problem that the target i.e. the AVR device is not crystal controlled (well certainly in the low pin no devices and specifically in the jpg you show) thus it is the AVR that has the most problems with timing. All uarts (or uart / usbs) fundementely are crystal controlled so they are expecting exact timings (ish) hence the slower you can run the comms (within limits because when you get too slow { within the specified baud rate } paradoxically this super accuracy causes problems) from the AVR the better the results will be.
This accuracy at low speeds was the original reason that telex and TTY's used 110 and latterly 300 baud it was (is) inherently reliable though slow despite the mechanical jitter on the clock generation of those days. Also I suspect the main reason that telex was the only mechanical transmission of data deemed to be sufficient for legal document transmission though I never got my head around what about when the paper ran out / stuck because all you could see was a very good black rectangle!
I found this (and that's why there is a strug 62000 in the code { sorry forgot to remove it} ) was most reliable. Using your code, what I did was to let it find the speed (which often {well in my case always} did not work for the actual debug session as it would always fail on a big data transfer e.g. flashing .) for connection (of a 1:1 mark space ration "U" is 1:1 right down to start and stopbits at 1 of each). and then reduce it via the command line until it was very reliable. Usually (always ) using the lower end of the spectrum, all this was emperical as I don't believe even with very sophisticated analysis I could provide an algorythm that worked 100%
Most of the time if I used the defaults your code calculated it would respond with the incorrect no of returned bytes.
Interestingly when I moved the 2313 to another part of the board (for testing I used a solderless board) it would lock in at 37000 ish (can't remember the exact value) but after a few goes it would come back to 62K (pass one day I may investigate but at the mo I'd prefer to get on with using the s/w {bugs and all} to debug some code I've written)
As an aside I was wondering about making PC single command SP single command x,y,z same also I was going to change "r" to "x" purely because SID used "x" and it's instinct to hit "x" not "r"
I,Z,C etc as single toggle commands e.g. command "Z" toggle the zero bit in the status reg purely for speed I'm very used to reading and writing the SREG and then binary mod but toggle seems a good idea.