What am I too stupid to understand?

[Dylan]

Ok, I'm either lost or stupid.

I've had a Duinomite (regular + IO) for a few months now. Dared to upgrade to MMBasic 4.3A and modded my continuous servos to pretend to be regular ones by bitbanging in basic, of all things.

With the source from GitHub, I get massive numbers of warnings before sufficient errors, and I'm even able to find the old compiler recommended (http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1406&dDocName=en023073, google: mplab ide archives because it ISN'T loading today, kk it just did). But this is not about Duinomite as such, in fact I would like to install Pinguino and get OTG functionality (for Android Open Accessories; Tsvetan kindly sent me a link for ADB, but I want more).

So I wrote a program to look at what addresses are used in .hex files. The bootloaders (supposedly at 0x1fc0_0000) are implemented in

Code Select Expand

filename = 'DuinoMite_MMBasic_V4.3A.hex'
filename = 'Maximite-Olimex.X.production.hex'
filename = 'UBW32_HIDBoot_MX795.hex'
as less than 48 bytes

FFS:

Code Select Expand

:020000040000fa
:020000041fc01b
:042ff000ffff07a632
:020000040000fa
:020000041fc01b
:042ff400d979f8ff90
:020000040000fa
:020000041fc01b
:042ff800dbde60ffbd
:020000040000fa
:020000041fc01b
:042ffc00f7ffff7f5d
:020000040000fa
:020000041fc01b


So in the 12k bootloader, the last 16 bytes is encoded in 12 lines, 4 of which reset to 0x0000, three of which (reduntantly) back to 0x1fc0, but then painfully by 4 bytes at a time.

There is clearly a jump at 0x01fc0000 to regular flash, but it is clearly microchip's own tools generating this crap (tools based on GCC toolchain, as I understand it).

Surely (please, pretty please for the sake of my sanity) the 12K bootloader should not ever be overwritten by a "program", the entire point of having that 12K extra is so that one cannot brick their Flash device.

[Andrew]

MX795 has got 128k sram, and able to run from sram instead of flash. If it is configured to cache whole flash into ram on application start, it can reprogram the whole flash without crash. However in this case, the key is _without crash_. If reprogram crashes, it will leave a crashed flash behind, and will not start anymore. You can test it with a broken hid reprogram - just pull off the cable while reprogramming. If it not starts anymore, test passed

[Dylan]

Obviously the whole flash cannot be written; do you mean just the additional 12k boot flash?

I'm still missing something more than that. For example, there is no point in running from RAM instead of flash, but it DOES make sense to use RAM first during the process of replacing the bootloader (i.e. the running code), and then doing the MIPS/flash equivalent of REPx MOVSB.

[Andrew]

There _are_ some point to run from sram instead of flash.

First: speed
Program can run up to 20 or 30 mhz (dont know accurately) from flash without wait cycles. If you want more speed, you have some cache lines, _and_ the whole 128k sram. You can use it as workspace, stack, even program memory. If you run program from sram, you can hit 80 mhz without wait cycles, and that is much speed bonus if you need it.

Second: power consumption
If you run from sram / cache lines, you have about half power consumption. However it can be important in some rare cases only, it is still a benefit.

Third: flash reprogramming
While your application runs from sram, you can reprogram the _whole_ flash (boot + program flash). The only point: dont crash, while you are doing so. If you crash, you have to use pickit3 or jtag to recover.