MarOS1.5.0 - Beta Version Moderators: altitude, adafruit_support_bill, adafruit, hamburgers, phono

[Nordcore]

I think it was just a simple not properly flashed program. That happens from time to time. In fact it happens that often, that I would prefer a 32 bit CRC ... but the code space restriction does not allow that. (The 8 bit CRC is the one already needed by the computer control code, so a good part of it comes for free... )

Switching to and from BOOTLOADER whilst powered up does nothing. The decision for BOOTLOADER oder normal code is done only once a few milliseconds after power on.
The only thing you can handle wrong during update is to switch power off or unplug the USB cable. Then there is a not complete program in your x0x. Which might crash in older versions and go to "DOWN and DONE" in newer ones.
(The check code is intentionally placed in the beginning of the firmware, so there is a high probability that it is written properly. Most programming errors are lost characters - and everything after such a lost byte is broken/will crash. )

BTW: It is not possible to break the boot loader with the update procedure.
The boot code has a separate code space (a whopping 512 bytes) which can only be written by a hardware programming device.

[Paradigm X]

thanks for the reply. glad to hear i cant mess it up by flashing.

it was just i saw a message in Conb0x which said 'dont connect to x0x0b0x in bootloader mode!' which made me think id done something wrong.

either way all good now. will flash my other x0x when i get a chance, but going to do some mods and replace the tacts.

cheers
Ben

[antto]

BTW: It is not possible to break the boot loader with the update procedure.
The boot code has a separate code space (a whopping 512 bytes) which can only be written by a hardware programming device.

sadly, it is
there are lockbits which let you "lock" the app and boot sections from writing, and in our situation the lockbits should be configured to lock the boot section from writing
but it turns out that quite a number of pre-flashed atmega162s come unlocked, including mine.. guess how i learned that

the unreleased v1.02 of c0nb0x includes some checks for that reason
it requests the fuse and lock bits from the bootloader, and prints a warning if the boot sector is not locked
here's what happens with one of my x0xb0xes:


0xFF is the default value, all flash sectors are writable

[antto]

thanks for the reply. glad to hear i cant mess it up by flashing.

it was just i saw a message in Conb0x which said 'dont connect to x0x0b0x in bootloader mode!' which made me think id done something wrong.

either way all good now. will flash my other x0x when i get a chance, but going to do some mods and replace the tacts.

cheers
Ben

here's the situation with the old bootloader (i call it x0xb00t1)
- it has absolutely no feedback, you cannot figure out if you're running the bootloader or the atmega is frozen into a bad loop due to corrupted/missing firmware
- it uses a very primitive serial protocol, with single character commands
-- this means that by merely sending any random junk to the USB, anything that gets thru the USART receiver as valid data bytes - you may get the bootloader into programming mode and you may clear a page, you may change the address for the next page, etc..

if the boot sector was properly locked via the lockbits - at worst you would corrupt your firmware only - and that's not terrible
but since on some (or many) chips it seems to not be locked, then you can in theory corrupt the bootloader itself

now, to actually send data to the x0xb0x (besides modifying the ft232 chip out) you need to connect the USB to a computer, where it will appear as a virtual serial port
so, any program which opens that serial port and sends the "right" kind of data to the bootloader, could potentially corrupt it
that could be a serial terminal program (like realterm or many others), or one of the dedicated x0xb0x apps
the x0xb0x apps (c0ntr0l, c0nb0x) can talk to the bootloader, or to the firmware
but they don't know what they talk to.. not easily
so it's left in the hands of the user, to be careful

do not tell the program to connect to the firmware, if the x0xb0x is running the bootloader
because the serial protocol between the firmware and the app is more complex, and thus there is more data going on, so chances get higher to hit some magical combination of junk data that causes the bootloader to attempt to shoot its own foot

especially do not do it with c0nb0x, because c0nb0x uses even more app<->firmware messages, and sends a bunch of queries on connect to figure out what firmware it's talking with
the mentioned c0nb0x v1.02 includes a check for that, when you tell it to connect to the firmware, it tries to safely detect whether the x0xb0x is actually running the x0xb00t1 bootloader first, before sending a pile of fancy messages
this is also included in the c0nb0x_wx (the rewritten version which is also not released yet)

that's the situation with the old bootloader.. there's not much that can be done about it
unless everyone buys (or makes) a programmer to lock their chips

[Paradigm X]

Well, a bit more carefully, i updated my other x0x last night. backed up all patterns in c0nb0x and then updated firmware, worked first time.

then had a 2 hour jam with the two boxes, had so much fun, this latest version is superb, subtle use of randomisation in play mode is fantastic, the new save pattern method is great (lost so many patterns messing about with done button), overall seems much more stable and tighter syncing, overall just really pleased with it.

So thanks so much to nordcore, mario, antto, sokkan and all others involved with keeping the x0x moving forward!

cheers

[Paradigm X]

I twigged the run button = stop pattern/restart synced to bars function last night, so much fun! this thing gets better and better.

thanks once more

ben

[Paradigm X]

ok well something ive found while playing;

If in play mode you set a loop less than 16 notes (using done and 1-16) if you press run then restart again using run, it goes back to a full 16 note loop. i had anticipated it would remember the shorter loop settings.

not sure if a bug or wai or limitation of the way it works? not a major problem but would be great if it could work as i thought it would.

still loving it btw, it just seems really solid and tight, everything works perfectly with no little odd occasional glitches i got with sokkos now and again.

cheers
ben

[Nordcore]

not sure if a bug or wai or limitation of the way it works?

It's worse: it is how it should work.

Removing that would even save some byte.
I think I can add a User-C setting to enable/disable the "loop reset on STOP".

[Paradigm X]

ok, well thats no biggie, just wondered. an option woudl be great if possible but not a major priority.

still loving this so much! its so tight and just works really well. all the little syncing problems i had are gone!

if i may add a feature request (if possible) - when you press run/stop to stop start the sequence, would it be possible for the run/stop led to flash so you know its going to stop/start? not critical by any means but theres no way of knowing if its registered. not a big thing but would be awesome if its easy.

thanks so much.

[Nordcore]

I noticed that (somewhat broken looking) missing feedback by the R/S LED (in MIDI-Sync while it waits for the next bar) also.
I try to squeeze some LED blinking in the code. It is not complicated, but a little bit lengthy...

[Paradigm X]

hi. it doesnt necessarily need to flash, im not at my x0x now but as i recall the run leds isnt lit when midi synced? a solid on led would be fine if easier/smaller.

brilliant.

thanks, ben

[antto]

not sure about sokkos and its derivatives, but at least in the stock firmware there's a famous LED blink bug when you're in slave mode
the LED blinking is controlled by the incoming sync clock (as it should) but there is also a chunk of code that does a fixed-rate blink, and the two effectively XOR each other

[Nordcore]

Yes, this bug was there. I fixed that some (not too long) time ago.

... and being there: I added some "timeout" code, so you could still STOP the x0x in MIDI-Sync-Mode when the external clock gets lost.

... and I'm thinking about an "auto sync source" mode, where a missing clock switches to internal clock. Plus synchronizing the internal clock speed to the external sync. That could provide a bullet proof clock output, that would still continue, even it if the source gets lost (stupid DAW programs, crashing Laptop, flimsy cables...)

[manneokoko]

Hello Nordcore and all,
What a nice surprise to see that this OS is still being developed!
I have a couple of feature requests that would improve the box allot, maybe not possible but..
Improved Live record.

1. When a note is pressed down during several steps then all steps should get that note. (now it will only record the exact step where you start pressing the key, not the following steps when you keep pressing the key)
2. If R/A/S/U/D buttons is pressed down during several steps then all those steps should get R/A/S/U/D (not only the initial step that is held down).
3. Some way to clear R/A/S/U/D while live recording - maybe hold down one of the R/A/S/U/D + press DONE.
4. Alternative way: note + R/A/S/U/D can be recorded simultaneous: When you hold down a Note key+R/A/S/U/D, note and R/A/S/U/D state will be input for all the steps that pass when held down.

Possibility to set root key for the randomizer.
Now it always randomizes in C, and then we have to press D/U to transpose to the right key - it would be better if the transpose setting is kept even when making a new randomization.

What do you think is any of these possible?

[ioth]

Hey Nordcore, found snother small bug, when in randomizer mode pressing the F key twice it clears tha pattern (thats right),
but it also sets the length to 15 steps. would be cool if it always goes to 16 steps.

Best, ioth