New CPU Project

[Altitude]

I tried by putting the select switch to bootload and then trying to connect via c0ntrol and c0bb0x, neither worked. When in bootload mode (via select switch) with would give a bunch of LEDs on, then one led (step 16) and I could then go back the to the regular modes via select switch which doesnt sound right, I was under the impression that bootload mode would put it in a loop.

Some additional info: The JTAG programmer I got was a wash, I could ready and write the fuses and lockbits but couldnt write the flash, it would return 0x00 for everything on verify,

The way I did get it to work was to remap the ISP pins like you mapped out and write it with my AVRISP mk2 via avrdude. Is there anything in particular I should try with regard to the bootloader? I assumed it would be no different when writing bootloaders for other devices (i.e. Mutable Instruments stuff)

One other thing, the way this board is set up, the ISP pins are not wired correctly. They are wired 1:1 off the spec sheets so the MISO and MOSI pins are wired to pins 6 and 7 of the 40 pin connector, not like in your instructions (10, 11 pins). This is why I could never get the ISP programming to work right until I read the bottom of your wiki post about the pinswap. IDK if this would mess up the functionality of the bootloader..

[guest]

c0ntr0l and c0nb0x wont work
this new microcontroller has a larger memory than the others
and therefore needs an entirely different memory addressing scheme
so a new bootloader was required

sorry to hear about the jtag not working
sometimes they return fail on verify
but the code actually loaded fine

to load the bootloader
you might have to set the memory address you are putting it into

to test out the bootload mode
try using avrdude to put the code in
or install arduino and test it from there

[antto]

on the old x0x cpu (atmega162) the bootloader sits on the last 512 bytes from the flash memory
so when firmware is uploaded - it is written at the beginning of the flash
there is a way to configure the cpu (i forgot whether it was lockbits or fusebits or what..) how big the bootloader is
there is also a DeviceID command, where the bootloader responds with the magic "x0xb0x1" string

when c0nb0x connects to the bootloader, it asks for this DeviceID string and expects to get proper reply, it also asks about cpu model and then asks for the address of the bootloader (in order to compute the total free space available for firmware)
if any of the conditions are not as expected - it either warns the user and requests confirmation, or simply aborts with an error message

on the new cpu.. i breifly looked thru the bootloader code, but i didn't see a similar DeviceID string command
it's not a big deal as long as it can be determined whether the cpu is atmega2561 and the address of the bootloader (via serial port)

[guest]

the whole bootloader needs to be different
since there are different commands to access the larger memory space
im not certain if putting those other things in
will get avrdude to do the right thing or not

its probably best to get the new one working first
and then work towards backwards compatability

[Altitude]

Can you post step by step commands for loading the bootloader via avrdude? I was able to flash the firmware without issue and that worked fine but I very well may have over written the BL in the process.

As far as the JTAG, I dont think the one I have supports the bigger chips, its simply a clone of the old serial port one slapped on a USB->serial chip. I can read and write the fuses with and all other maintenance stuff but not code

[antto]

guest: yes, it should be a different bootloader, no need for it to be backwards compattible with c0ntr0l or c0nb0x
it's nice for the control app to be able to "ask" the bootloader for cpu model and such things, just to make sure the user isn't drunk or something, but of course it's not "required"

it's also cool that the baudrate is higher while the bootloader is running, this will make firmware upload faster compared to old cpu
..speaking of which.. i haven't looked thru that part of the bootloader code, but we might want to implement a custom mode, where the app will send the .hex data in big packets with a simple CRC at the end, and the bootloader will have to reply after each such packet with either OK / CRC_ERROR / BAD
so when the app receives a CRC_ERROR - it will retry sending the last packet again

my "serial" connection with the x0x is kinda lossy, it's noticable when extracting patterns via c0nb0x - sometimes (more often than i'd like) data gets corrupted and CRC fails on some patterns (c0nb0x retries..)

[guest]

so i tried to use avrdude to upload the bootloader
but i could not get avrdude to work with my jtagice mkii
after a long time i got it talking
but it wouldnt set the fuses right

so i loaded the bootloader with avrstudio
if you have a windows box
i would reccomend avrstudio
everything is just point and click and youre done

but the basic steps for using avrdude would be
1. load the fuses except lock fuses
2. load the bootloader code only
3. set the lock fuses

then use avrdude to bootload the actual code onto it
trying to write the code with a programer will just overwrite the bootloader
to use the bootloader
1. put the x0x in bootload mode
2. power it on
3. connect up the usb
4. find the comport that the x0x is showing up on
5. then type the magic phrase
avrdude -p atmega2561 -c stk500v2 -P YOURCOMHERE -b 57600 -e -U flash:w:x0xb0x2.hex

the x0x should then work as usual

i changed one of the fuses while going over it this time
there is an option to use a full swing oscillator
and i decided to go with that rather than the low power oscillator
because it is more robust
every so often on the old x0xen there would be someone who had a crystal
that just wouldnt oscillate for them
unless they wiggled it with their finger
and i think this will help with that
it probably doesnt make any difference
but i figured why not

[Altitude]

Ah, this makes a lot more sense now. I kind of suspected this is how it was supposed to work (i.e. the USB/Serial thing was just emulating a STK500 programmer). I'll give it a go tonight

[Altitude]

Ok, Progress:

Got the bootloader on the chip via AVRisp MKII and AVRstudio and verified that the USB serial port now emulates a STK500 programmer when the dial is in the bootload position (times out anywhere else). I can talk to the chip via USB this way to check device sig etc.

Flashed FM with avrdude and I am up and running!

(had the wrong lock bits set previously)

[roxxx303]

Hi,

as I understand the new CPU for the x0xb0x is available now. A lot of people waited for years for this!
Hundreds of new OS-Functions will be possible now!
But nothing happens...

Is anyone working on new CPU-addons for x0xb0xes/x0xb0x-kits or is programming a new enhanced OS ?

[antto]

it's not quite available, textile dissappeared
currently only me and Altitude have these
mine doesn't have a bootloader so i basically can't do anything with it untill i put a bootloader on it

[Altitude]

it's not quite available, textile dissappeared
currently only me and Altitude have these
mine doesn't have a bootloader so i basically can't do anything with it untill i put a bootloader on it

So, um, why not go ahead and put the bootloader on it already

[antto]

yes, i'll have to buy a programmer for that
right now i'm looking to buy a drum machine, and i'll see how that'll go

[Altitude]

This should do it: http://www.ebay.com/itm/USBASP-USB-ISP- ... 53f62de51e

Cant beat the price

[antto]

doesn't ship to my silly country ;]
i'll look around for another one

edit: would this one do the job?