0

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

Please be positive and constructive with your questions and comments.

Re: MarOS1.5.0 - Beta Version

by Nordcore on Tue Aug 29, 2017 8:19 am

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.

Nordcore
 
Posts: 71
Joined: Sat May 23, 2015 3:14 pm

Re: MarOS1.5.0 - Beta Version

by Paradigm X on Tue Aug 29, 2017 10:14 am

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
User avatar
Paradigm X
 
Posts: 231
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

by antto on Tue Aug 29, 2017 12:48 pm

Nordcore wrote: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:
Image

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

antto
 
Posts: 1570
Joined: Thu Apr 15, 2010 3:21 pm
Location: 127.0.0.1

Re: MarOS1.5.0 - Beta Version

by antto on Tue Aug 29, 2017 1:11 pm

Paradigm X wrote: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

antto
 
Posts: 1570
Joined: Thu Apr 15, 2010 3:21 pm
Location: 127.0.0.1

Re: MarOS1.5.0 - Beta Version

by Paradigm X on Thu Aug 31, 2017 4:42 am

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
User avatar
Paradigm X
 
Posts: 231
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

by Paradigm X on Sat Sep 02, 2017 2:39 pm

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
User avatar
Paradigm X
 
Posts: 231
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

by Paradigm X on Thu Sep 07, 2017 6:20 am

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
User avatar
Paradigm X
 
Posts: 231
Joined: Sun Feb 07, 2010 3:49 pm

Re: MarOS1.5.0 - Beta Version

by Nordcore on Sat Sep 16, 2017 8:09 am

Paradigm X wrote: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".

Nordcore
 
Posts: 71
Joined: Sat May 23, 2015 3:14 pm

Re: MarOS1.5.0 - Beta Version

by Paradigm X on Sun Sep 17, 2017 10:10 am

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.
User avatar
Paradigm X
 
Posts: 231
Joined: Sun Feb 07, 2010 3:49 pm

Please be positive and constructive with your questions and comments.