i already have a randomizer coded into c0nb0x (tho, it's not in v1.00)CTRL+8 - randomize TMCTRL+9 - randomize PM

my internet connection is pretty broken, so reuploading ~1.3MB is a very tough job (it took me like 4 hours now)and don't forget that i rely on another person for the mac-osx version, both for compiling and testingfortunately, OS-dependant stuff hasn't changed since v0.99 thus there wasn't any huge need for testing

i want to see if there are any other issues with this versionlike if anything bothers you - just shout

i also want to see what's new around the CPU mod, since that can affect the future of c0nb0xfor those who haven't read - i wanted to change the serial protocol because there are some unneded things, like packet format having uint16_t size while the maximum size of a packet cannot be bigger than the uart buffer which is already defined as 64 bytesremoving 1 byte from the packet (making the size simply uint8_t) and thus removing the small integer math involved in converting it would free up some tiny fraction of code spacei wanted to put these changes in the current OSes (adafruit 1.05, n0nx0x and sokkos) but i didn't really get any response from sokkan and maybe that's right - such modification would make the current OSes completely incompatible with c0ntr0l (only firmware will be still flashable)

but such serial protocol modification can be implemented perfectly in the brand-new upgraded-cpu firmwaresince c0ntr0l already won't be compatible with it (i think)then, this can be used as the foundation firmware for all othersthis would be doable because the new CPU has 256kB flash, that's much much more than the original x0x cpu

The app is compiled in OSX 10.7 and it has been made to work in earlier versions starting from 10.4 (Intel). This has NOT been tested this because no macs running 10.4/10.5/10.6 are around.. If it works fine in any of those systems, please report back here!

hi big help neededi'm having all the exact same problems gompie was having right down to a ti'm using c0nb0x and attempting to flash new firmwarei was running sokkos 1.9 prior to even trying this at all and all functions were finei'm using win 7 64bitafter trying like 20 times i eventually got firmware to upload and all done fine...oddly enough i can only get it to work just like he did by working quickly, ie power on in bootload--->straight to upload firmware

:( but now x0x is stuck in perma-bootload mode - none of the modes work and some/none/all of the lights come on when powered onneedless to say it makes no sound eitheri usually have the x0x din synced (as slave) to my 606 which oddly enough wont operate unless sync cable is unplugged nowi've tried flashing a few different firmwares countless times now to no avail - perma bootload/crash mode is all i getPlease help - been looking forward to trying this Cheers

might be worth noting that prior to this computer control mode was working fine alsonow i get timeout errors trying to import/export eep and patterns :(

Last edited by Cocker on Sat Nov 24, 2012 4:40 pm, edited 1 time in total.

hi cheers for quick replyusing v1.0was having exactly same issues as gompiesame screen caps he posted back a few pages ago. all the things he described except on win 7at moment i can still upload firmwares successfully if i move fast, but then i switch off x0x, change modes, remove usb, power onand i am stuck in boot/crash mode in every mode

already with "Ping Bad" it means that there's something wrongand the following tests confirm that

so it sometimes works, sometimes not?that's odd

are you using some extremely long or bad USB cable?i'm not sure how to help if it's something to do with the hardware

but if you manage to upload firmware sucessifully - that means that there is a bootloaderwhy it works *sometimes* is a different question

oh, i got an idea.. when you "Connect to x0xb0x" and all tests fail, when you get to the actual menu, check the connection statusit should show something like [Rcv:Err:CRC: X / Y / Z]with 3 numbers, number of packets received, number of errors, and number of bad CRC packetstell me what it prints there immediately when you see it

1) I have seen many times (maybe 5% of all uploads) that the firmware is partly broken after upload. Uploading again always helped, but: it`s definitely a matter of what else the computer is doing. When a audio DAW is running at the same time at 40% CPU load, actaully NO upload will ever be working on my system. So make sure you close other applications. I have not seen in any case, that this would overwrite the bootloader part (unless the hex is too big, and you run conbox0.99), so I would not worry too much now:)

2) My power supply is a little weak, so after turning on the box, it is sometimes not feeling quite well. Normally this seems to be indicated by many LED turned on. So I turn on and off a couple of times, until it looks ok.

when i was "brewing" the serial port code, i noticed that i get bad bytes from time to timemy x0x powersupply is 600mA and i have normal red-leds (sanely bright)

this happens at all times, doesn't matter if you're sending a hex or extracting patterns

but when extracting patterns, or in other words, when the x0x is running the firmware - there is a CRC check on each packet at all times, and c0nb0x checks that, and automatically retries when a CRC error happens during pattern extraction

unfortunately, there is no CRC nor any other error checking during hex uploadthat's how the bootloader works and i cannot change it

RS232 is also sensitive to timing, try and set the Baud rate to something slightly lower or higher than what it should be, and you'll start to get more and more bad bytes

I know you`re on win, and me too, so from what I saw here, I`d say the app should get a better threading priority. Here it`s set to "normal", but when doing things that critical it should clearly be set to "realtime". No idea how to that, though.

it's the OS which does the actual RS232 stuff, which itself is virtual, the USB-Serial driver is what actually sends the datai cannot do much from the appand i don't think chaging it's process priority would help

Hi. thanks for replies. sorry was out of contact there for a few days. just tried all this again.Gonna apologize beforehand for the big post and all the caps but i thought maybe you might see something i'm missing.

I'm not running any other applications while i'm doing this. i've tried all this with a different cables and different portsi have yet to try it with another pc but here's what i get shown in a few screen caps

*do note that i was running sokkos 1.9 prior to this and it was working fine.**i was also able to use computer control mode with c0nb0x

1. power on x0x in bootload2. open c0nb0x and device manager - make sure all ports etc are correct3. all good so far. settings checked ready to go4. run diagnostics mode and get this

5. if i then try connect to x0xb0x i get this

6. now if i try and upload a firmware after all this, i cannot. i get this

7. however, if i shut everything down and restart x0x in bootload, load c0nb0x and run through the firmware upload nice and quick it works fine and i get this. looks good...

8. firmware uploads successfully. i get this

9. switch off x0x. change to any regular operational mode and nothing works. no sound. no sequencer. looks like still stuck in bootload mode. (some/none/all of LEDs come on each time i power on)

10. back to bootload mode. open c0nb0x. connect to x0x. get this

11. if i try computer control for import/export i get this

Anyways, while I am familiar enough with computers and and software and stuff, I don't know much about coding or electronics so I fear what that what I may need to do to fix this might go a bit over my head. If worst comes to the worst there is a guy in my city that should be able to get it up and running. Would be nice to sort it from home though.

only "Upload firmware" is what you need the bootloader forin all other cases, you shouldn't be in BOOTLOAD mode

for "Computer Control" as well as Diagnostics** mode - the x0xb0x should be running the firmware, not the bootloaderif you still find this confusing - watch the tutorial video about uploading firmware, the link is somewhere on the first page of this thread

** this feature basically doesn't work because i haven't released that special firmware, so don't bother trying it, it will never connect

so, you can see you get a few Err packets which means that the x0x is there and responds, but it's in bootload mode and the data it receives is unexpected (c0nb0x is trying to talk to the firmware)

the fact that you can flash firmware means that the bootloader is there

restart the x0x in any mode and try to connect via "Computer Control"- if it fails to connect and you see Err packets happening like in your later screenshots - this means the x0x is replying to the data but in a weird way which either means there's something wrong with the data happening or it's in BOOTLOAD mode again? while it shouldn't be- if it fails to connect and you don't see Err packets or any other stuff (all 3 numbers there would be zero) - this means the x0x doesn't respond at all for some reason (or no data arrives at all, not even wrong data)

if you manage to get it to connect properly, try to extract the eeprom a few times to see if you get lots or Err or bad CRC packetsif you do get CRC errors - it's what i suspected, the connection is "flakey" for some reason, packets tend to get corrupted too oftenthat would explain why flashing firmware works "sometimes"

my mistake. although i am aware that the bootload mode is firmware and computer control is for memory and patterns import export. i've been using it for storing patterns right up until i decided to update my firmware

here's rundown of the issues i'm havingprior to updating the firmware i was using computer control mode just fine for import/export of patternsbut i could not get new firmware to upload. eventually i did get the firmware to upload (by doing it quickly)but now nothing works and my x0x does not work in any mode (whether connected to my computer or not)

now when connected in computer control mode, first i get the Ping.. BAD messagethen i have to skip the fw detection and bpm bit to get to import/export page

when i export memory/patterns i get this "unexpected packet" error like this

this eventually times out and i get this

i've tried all sorts of permutations of all kindsnot sure where to go from here :(