LP-MSPM0G3507: Lauchpad in funny state, how to reset

Did you try the BSL trick?

1) Press and hold the NRST and S1 (left side) buttons

2) Release NRST, then S1

3) Immediately start your code download. (I read somewhere about a 10-second BSL timeout).

Worked for me.

Just tried, I still get the error -6305

Oh this is interesting, doing a low level cmsis-dap connection, I can't connect to access point 0 (it doesn't exist); but I can connect to access point 1 (IDR = 0x002e0001). So if i knew what values to write to what addresses, I may be able to get back into it.

Alas access point 1 is usually proprietary, so I'm guessing only TI know what it accesses, and what you can change ...

On AP=1 I can read registers about 0x1000000 it doesn't look like my code - but is numbers read from the device, which is a good sign. Under the assumption these are memory address (BIG ASSUMPTION), giving addresses of NONMAIN area of memory, and everything there is 0x00 - which if it is reads from memory would explain why I can't boot ...

and if it helps anyone at TI to know whats happening under AP=1 the first few registers on read give

0x1bb8802f
0x80c7ae2d
0x40000010
0x00000000
0x00000036
0x00000096

Hi David,

AP=1 in the MSPM0 is the CFG-AP, and provides some basic device information in addition to being used for logging some potential errors, including a boot diagnostic error that would be associated as a CRC failure for the trim regions, BSL, or BCR configuration regions. 

I don't have a decoder for what that diagnostic error would be or where it would be placed, but I am checking on that to see if I can gleam anything from what you shared. 

In the meantime, have you done any modification to Non-main? 

Best Regards,
Brandon Fisher

I issued a command, a side effect of which was to erase the flash. Due to a coding error, it also erased NONMAIN, or at least that what I suspected happened. So I'll have written to both the SWD and BSL registers which enable them, and so I suspect disabled both in one go!

What I was hoping was via AP=1 I could switch back on SWD, possibly after another mass erase. Then at least from SWD, I could type by hand the correct values into NONMAIN, and bring the launchpad back to life.

If there is no way via AP to switch back on SWD, suspect I have just totally bricked the machine.

Have dug some more. I can access AP=1 and AP=2; all other AP no longer exist.

So guess the question then becomes in AP=1 or AP-2 is it possible to renable  SWD?

Another possible direction, in this locked mode, is JTAG respected? the 48 pin MSPM0G I guess has enough pins to have a full jtag - just need to check what those pins are and where they come out. In theory I've the FTDI cable that can be used for JTAG, but have never used it for that - but gives another possible direction.

So from section 26 of the TRM, if I can write to the DEBUGSS Registers, in particular to SPECIAL_AUTH @ 0x1200, I can change access to SWD.

Now from what it looks like, AP=1 access AP registers in the range above 0x1000000, whilst AP=2 access AP Register on the range 0x2000000 and above.

So this suggests to me that only AP=0 can access 0x1200 and the SPECIAL_AUTH that can enable SWD; and as I can't access AP=0, so I can't access the register.

There is a fair bit of reading between the lines. e.g. the AP registers that the CMSIS-DAP interface is showing, are the same as the DEGUGSS offsets show in section 26 of the TRM.

And where I've got to today.

What I probably did is erase the NON MAIN area of flash by a coding mistake.

The critical variables I'll have erased (to value 0xffffffff) are BOOTCFG0, BOOTCFG1, BOOTCFG2, BOOTCFG3 - there are a string of others connected to BSL, but should be fine. My CRCs may or may not be rubbish.

Now all documentation says that doing this completely closes down SWD-DAP and the BSL, so machine is fatally bricked.

However connecting to the CMSIS-DAP and although AP=0,3,4 are down, AP=1 and AP=2 are still alive. I can't say whats in AP=2, but AP1 seems to be 64 words, values then repeat. It seems strange that AP=1 and AP=2 are still open, everything in the documentation says they should be closed down - so this is undocumented.

The TRM section 26, says AP=1 is configuration, and AP=2 is debug mailbox.

What do I need to do to get SWD up (if indeed its possible), well doing the raw write equivalent of:

  DEBUGSS->SPECIAL_AUTH|=DEBUGSS_SPECIAL_AUTH_SWDPORTEN_ENABLE
    |DEBUGSS_SPECIAL_AUTH_SECAPEN_ENABLE;

May work, I say *may* as its read only in the SDK, and that suggests this peripheral register maybe only reports the status, and can't be used to set.

Other than this I need a way to rewrite a few variables in NON MAIN, which can only really do from SWD, so question is there a back door anywhere?

Now Section 3.2.4 of slau887.pdf Bootloader user guide, says I may be able to use the DSSM (Debug SubSystem Mailbox) to start the bootloader - and the DSSM is on AP=2, which is one of the few AP that is still alive. Now the bootloader may refuse to start, as the NON MAIN variables are rubbish; but this isn't clear, and so an option. How one uses AP=2 (DSSM) to start the bootloader, also isn't clear to me ... Also how to get DSSM to launch the boot load via the AP=2 registers, I think also isn't clear.

So this only really leaves, has a back door been left in AP=1 or AP=2 where by with trashed NON MAIN, I can get back into the machine, and write corrected values to NON MAIN?

And checking the MSPM0G chip data sheets, and it looks like JTAG is never provided; its always a SWD connection, and that SWD connection depends on the boot rom to come up, so its a software provided interface.

And where I am this morning.

Writing DEBUGSS->SPECIAL_AUTH seems either not possible, or not useful. The TRM gives that its read only (either by constraint, or that it only give information, but does not control behaviour).

So this gives the DSSM AP=2 as most useful. Its clearly possible to send messages that are useful with the DSSM, this is documented all the way through the TI documents, there is a DSSM Factory Reset (maybe disabled for me), a DSSM message can invoke the BSL (maybe doesn't start for me). However two problems for me:

1. How to access the DSSM from the low level AP=2 regsiters
2. What useful messages I can send

Where 2 is tricky, is the question of who you can send messages to, who listens. Whats clear from the TI documentation is one thing you can talk to is the TI Boot program run from ROM, and that sounds where most functionality is. Alas I've not found any documentation, of what messages the boot rom code will react to.

Anyway if I can find out how to send messages through AP=2, and what messages to send to the boot rom, then maybe there is a slim hope. Also hopeful is the TRM does say, that for full lock down NONMAIN needs to be set read only, well mine is still RW, just with the wrong values in. So if I can get something to write to the NONMAIN via DSSM messages, thats maybe a way out.

Still not sounding hopeful though, there are at least two unknowns above ...

And a bit more reading, probably what I need to do is a DSSM Factory Reset - which I guess goes via the DSSM AP=2 which I still have running; and the factory reset also sets up the registers in NON MAIN to the original versions, and this will give me back my machine.

Now expect TI folk here to point me to CCS to use, so I've fired up CCS Theia. Its recognised I have and MSGM0G3507 plugged in, but how do I tell CCS Theia to send a DSSM Factory Reset via DSSM?

Hi David,

CCS Theia does not yet have an interface for this to my knowledge. CCS Eclipse does.

But rather than download CCS just for that, you can try the M0 Unlock GUI Instead: https://dev.ti.com/gallery/view/TIMSPGC/DSSM_Unlock/ver/0.0.2/

If the DSSM Factory Reset fails, it is probably disabled, meaning that NONMAIN was probably erased, and  you would be locked out. 

Best Regards,
Brandon Fisher

MO Unlock GUI says:

MSPM0G3507 selected
Calling gel function: Factory Reset

But the MSPM0G3507 doesn't restart

and:

pyocd> makeap 0
Error: no AP with APSEL=0 exists
pyocd> makeap 1
AP#1 IDR = 0x002e0001
pyocd> makeap 2
AP#2 IDR = 0x002e0000
pyocd> makeap 3
Error: no AP with APSEL=3 exists
pyocd> makeap 4
Error: no AP with APSEL=4 exists

So AP=0 hasn't be started. But AP=2 DSSM message is still that.

Now TRM gives the idea that everything is closed down, but with the DSSM message still up, I can clearly send messages to ROM booting. So what messages can be sent, that the ROM boot will listen to, what does it do, and what uint32_t do I have to send?

I can see you can send:

#define DSSM_BC_FACTORY_RESET                           (0x020AU)
#define DSSM_BC_MASS_ERASE                              (0x020CU)
#define DSSM_BC_PW_AUTH                                 (0x030EU)
#define DSSM_DATA_EXCHANGE                              (0x00EEU)

But how to I send these codes, events don't seem to have this information.

Are there any other codes, apparently one TI has to reset the machine, and do diagnostics.

Or are you saying anyone that accidentally does mass erase, might as well just thrown the cpu away, as it will never come out of ROM boot, and there is no back door?

It looks like AP register 0x2000000 = DSSM Register TX_DATA
AP Register 0x2000004 = DSSM Register TXCTL
AP Register 0x2000008 = RX_DATA
AP Register 0x200000A = RXCTL

It isn't clear that ROM boot is listening to messages.

Is this explained somewhere. Bits are in the TRM, but not everything. How the ROM boot work, very little is said. Is there anything I should be reading?

OK slaae29 gives a bit more information. CFG-AP and SEC-AP are enabled early. Indeed I can access under reset, and the information there is:

pyocd> initdp
pyocd> readap 1 0x1000000
AP register 0x1000000 = 0x1bb8802f
pyocd> readap 1 0x1000004
AP register 0x1000004 = 0x00000000
pyocd> readap 1 0x1000008
AP register 0x1000008 = 0x40000010
pyocd> readap 1 0x100000c
AP register 0x100000c = 0x00000000
pyocd> readap 1 0x1000010
AP register 0x1000010 = 0x00000000
pyocd> readap 1 0x1000014
AP register 0x1000014 = 0x00000055
pyocd> readap 1 0x1000018
AP register 0x1000018 = 0x00000000
pyocd> readap 1 0x100001c
AP register 0x100001c = 0x00000000
pyocd> readap 2 0x2000000
AP register 0x2000000 = 0x00000000
pyocd> readap 2 0x2000004
AP register 0x2000004 = 0x00000000
pyocd> readap 2 0x2000008
AP register 0x2000008 = 0x00000000
pyocd> readap 2 0x200000c
AP register 0x200000c = 0x00000000

immediately after reset is released information changes

pyocd> initdp
pyocd> readap 1 0x1000000
AP register 0x1000000 = 0x1bb8802f
pyocd> readap 1 0x1000004
AP register 0x1000004 = 0x80c7ae2d
pyocd> readap 1 0x1000008
AP register 0x1000008 = 0x40000010
pyocd> readap 1 0x100000c
AP register 0x100000c = 0x00000000
pyocd> readap 1 0x1000010
AP register 0x1000010 = 0x00000036
pyocd> readap 1 0x1000014
AP register 0x1000014 = 0x00000096
pyocd> readap 1 0x1000018
AP register 0x1000018 = 0x00000000
pyocd> readap 1 0x100001c
AP register 0x100001c = 0x00000000
pyocd> readap 2 0x2000000
AP register 0x2000000 = 0x00000000
pyocd> readap 2 0x2000004
AP register 0x2000004 = 0x00000000
pyocd> readap 2 0x2000008
AP register 0x2000008 = 0x00000000
pyocd> readap 2 0x200000c
AP register 0x200000c = 0x00000000

Register 0x2000000 is apparently DSSM TX_DATA - I can write to it and 0x2000004 turns to 0x1, so looks like 0x2000004 is DSSM TXCTL. It says I have written data to TX_DATA, and that the CPU (where the interrupt is sent) hasn't read the data. Indeed the TXCTL never changes from 0x1, so the boot rom never reads the message.

Conclusion. CFG-AP probably tells me of the status of the machine, but how to read the numbers is unclear. Haven't found anything that describes them.

The format of messages on SEC-AP/DSSM isn't clear other than for a few bits, how the bits are packaged isn't clear. Messages though are irrelevant, they can only be sent to the CPU, and the boot rom isn't reading the messages.

So conclusion is the MSP is dead. The launch pad now only has a slightly interesting MSP432 working on it, which can be used as a general SWD interface; but other than that, the board might as well just be discarded.

Its sad that this can happen as result of (accidental) mass erase - but it is what it is. I'll suck air on if I get a replacement. The MSPM0 SDK is a nice interface, I like the code there (when getting on top of it). The MSPM0 though haven't got enough information on wether its a useful device. It does need a big sticker on saying DO NOT MASS ERASE, which would look ugly, but then again is ugly.

Sigh. Oh well ...

Edit - just got some more information from the online factory reset, it did manage to connect to the SEC-AP port - and it wrote to AP register 0x2000004 the number 0x20b - which is interesting - my reading was that was TXCTL, which yes I'm allowed to write to, and interestingly it is different from the 0x20a I found above.

But does just seem to confirm that I just write these raw numbers to the relevant port. So if I get a new board I can check this.

I followed up with Brandon Fisher94 via private message - and he was being good about it, so its appreciated.

Anyway Brandon has gone quiet for a week or so, guess he is on holiday or something.

So let me go through conclusion (from my angle) of what happened, and why.

I was going through "pyocd" commands (I known this isn't TI supported - but its good for me, as works from the command line, and can be put in a make file - so I can do full build from the command line using make).

I issues the "pyocd" command "unlock" - what I didn't realise is this does a mass erase, that is documented else where on the pyocd site. There are some Arm cortex M devices where a mass erase, gives access to the device, and thats why "pyocd" has an "unlock" command. I've been discussing with the pyocd author Chris Reed @arm - he is another good guy, cares about what he does; and developing pyocd as a general cortex m dlap access device, it great that it gives "gdb" access to the cpu, so can do break points and the like. Now the problem with "unlock" is it unlocks some arm cortex devices, but for the TI MSPM0 family, it fatally bricks the machine, by clearing the NONMAIN area of memory. Chris Reed acknowledges this, and will look at ways round this.

But whats clear is that whilst nearly every other arm cortex device a mass erase is safe to do, for TI MSPM0 devices it is not, doing this closes down the BSL reset, and also the AP=0 generic interface needed under CMSIS-DAP. Indeed the only safe way to reset the MSPM0 devices, is not well documented, you can gather the information - but its hard to find. Specifically the only safe reset option is Factory Reset, done by writing 0x20a or 0x20b to AP=2 address 0x2000000 or 0x2000004 - have to be vague here, because I can't test these with a bricked device. Also what has to be clear is that this is a TI method for reseting the board, it is specifically not a general method for arm cortex devices, only for this specific set of devices.

Its worth going into how pyocd works, and why it was doing nothing wrong. pyocd works by using the CMSIS-DAP pack, and this TI does support, specifically: http://software-dl.ti.com/msp430/esd/MSPM0-CMSIS/keil/latest/exports/TexasInstruments.MSPM0G_DFP.1.1.0.pack

It is worth looking at the code that is used to program these devices in the file: TexasInstruments.MSPM0G_DFP.pdsc:

                <!-- *************************  Device MSPM0G3507  ***************************** -->
                <device Dname="MSPM0G3507">
                    <memory     name="IROM1" access="rx"  start="0x00000000" size="0x00020000" startup="1" default="1"/>
                    <memory     name="IROM2" access="rx"  start="0x00400000" size="0x00020000" default="0" alias="IROM1"/>
                    <memory     name="IRAM1" access="rwx" start="0x20000000" size="0x00008000" default="0"/>
                    <memory     name="IRAM_Parity" access="rwx" start="0x20100000" size="0x00008000" default="0" alias="IRAM1"/>
                    <memory     name="IRAM_No_Parity" access="rwx" start="0x20200000" size="0x00008000" default="1" alias="IRAM1"/>
                    <memory     name="IRAM_Parity_Code" access="rwx" start="0x20300000" size="0x00008000" default="0" alias="IRAM1"/>
                    <memory     name="NonMain_ECC" access="r"  start="0x41C00000" size="0x00000200" default="1"/>
                    <memory     name="NonMain_noECC" access="r"  start="0x41C10000" size="0x00000200" default="0" alias="NonMain_ECC"/>
                    <memory     name="Factory_ECC" access="r"  start="0x41C40000" size="0x00000080" default="1"/>
                    <memory     name="Factory_noECC" access="r"  start="0x41C50000" size="0x00000080" default="0" alias="Factory_ECC"/>
                    <compile    define="__MSPM0G3507__"/>
                    <debug      svd="03_SVD/MSPM0G350X.svd"/>
                    <algorithm  name="02_Flash_Programming/FlashARM/MSPM0G_MAIN_128KB.FLM" start="0x00000000" size="0x00020000" RAMstart="0x20200000" RAMsize="0x00008000" default="1"/>
                    <algorithm  name="02_Flash_Programming/FlashARM/MSPM0G_NONMAIN.FLM" start="0x41C00000" size="0x00000200" RAMstart="0x20200000" RAMsize="0x00008000" default="0"/>
                </device>

You can see how it describes part of memory, and even gives the code *.FLM for writing to these areas. The pack also contains these FLM files - they are just arm executables, and I can see they are linked against many of the standard TI library. The important bit to note is the "default" flag - now what this means in the CMSIS-DAP standard is default=0 means this section may be used, but could be superseded by another section, default=1 means this section *must* be used for writing to that area. So you can see that the pack has clearly said you should  write/read via the ECC areas of memory.

Now the interesting bit, is in the algorithm tags, the main memory has default=1, whereas NONMAIN has default=0. This means that writing to the main memory you must use the MSPM0G_MAIN_128KB.FLM algorithm, where for NONMAIN you *may* use MSPM0G_NONMAIN.FLM.

That is where pyocd has its problem, it used the MSPM0G_NONMAIN.FLM algorithm, and cleared 0x41c00000 area of memory so it followed a "may" instruction.

The underlying problem to my mind, is that the CMSIS-DAP Pack doesn't specify that doing a mass erase of NONMAIN  will brick the device, indeed it not clear to me how you could specify this. Maybe MSPM0G_NONMAIN.FLM should refuse to do a mass erase on NONMAIN, as on the MSPM0 devices you should never mass erase the area of memory - it make no sense. At best you may *very* occasionaly only write a few bits. [E.g. should the algorithm EraseSector and maybe EraseChip in MSPM0G_NONMAIN.FLM refuse to erase the NONMAIN memory error, and instead return status=1 so error - so only way to change bytes is the ProgramPage command, and erase is to write 0xff to a byte].

Another oddity, is that MSPM0G_NONMAIN.FLM does contain what the default values of NonMain flash should be. They are in nonMainDefaultBCR @ 0x564 and nonMainDefaultBSL @ 0x6e4 - but havn't yet found this referenced in the assembly. But does suggest that the NonMain algorithm does know that you need to be careful with writing to this area of flash.

Now mass erase could have also been made safe by having the words that give access to the BSL and CMSIS-DAP port as 0xffff. Then any bit flit would still lock the device (which is the TI design requirement), but a mass erase would just leave the machine open - which doesn't seem to have any security holes. But TI chose another word that means leave CMSIS_DAP and BSL open.

So whats the conclusion here. MSPM0 devices with respect to NONMAIN and device locking are very different from I think every other arm cortex devices, so have to be a special case. Oh course that doesn't help get the machine back - but does explain how these devices work.

I guess while talking of the CMSIS-DAP pack, there is a minor error in one value I guess its worth pointing out, so can be updated in the next release. Specifically the code explicitly tests the version number is greater or equal to 1; e.g. it does not apply to the development boards. But if you look at the bit that describes the launch pad:

    <boards>
        <board vendor="TexasInstruments" name="LP-MSPM0G3507" salesContact="http://www.ti.com/general/docs/contact.tsp">
            <description>MSPM0G3507 LaunchPad</description>
            <mountedDevice    deviceIndex="0" Dvendor="Texas Instruments:16" Dname="MSPM0G3507"/>
            <compatibleDevice deviceIndex="0" Dvendor="Texas Instruments:16" Dfamily="MSPM0G Series" DsubFamily="MSPM0G350X"/> 
            <debugInterface adapter="XDS110-ET" connector="XDS110-ET Onboard Emulator"/>  
            <debugInterface adapter="SWD" connector="10-pin Cortex Debug Connector (0.05 inch connector)"/>
            <feature type="USB" n="1" name="USB Device,  Micro-B receptacle"/>
            <feature type="Button" n="3" name="reset and two user push-buttons"/>
            <feature type="LED" n="4" name="LEDs for user interaction, including 1 RGB LED"/> 
            <feature type="ConnOther" n="2" name="40 pin BoosterPack Connector and support for 20 pin BoosterPacks"/>
            <feature type="TempSens" n="1" name="Temperature sensor circuit"/>
            <feature type="LightSens" n="1" name="Light sensor circuit"/>
            <feature type="SensOther" n="1" name="External OPA2365 for 4MSPS ADC evaluation"/>
            <feature type="XTAL" n="48000000"/>
            <feature type="Other" name="EnergyTrace technology available for ultra-low-power debugging"/>
            <feature type="Other" name="32kHz crystal"/>
        </board>
    </boards>

It clearly says it has a 48MHz crystal, this was true on the development board, but the production version of the board has a 40MHz crystal. So this needs to be updated.

@Brandon Fisher94 has gone very quiet, nothing in a month!

Can one of the TI people forward the above post onto the TI people responsible for CMSIS Pack, so they are at least aware of the issue?

Hi David,

Apologies for missing this, thanks for pinging me again here. It looks like I had previously marked this closed after we had moved to private message, and didn't see your previous post while I was out.

For the second issue involving the oscillator frequency I've filed a bug report internally. That should be pretty easy to correct.

The issue with pyocd you've identified is not one we've encountered on our end yet, I believe at this point we've only really used our CMSIS-PACK with Keil. We're also looking into support openOCD, although my understanding is that is not yet very far along. 

In Keil however you have to manually add the non-main flash programming algorithm (see here: https://software-dl.ti.com/msp430/esd/MSPM0-SDK/1_00_01_03/docs/english/tools/keil_ide_guide/doc_guide/doc_guide-srcs/keil_ide_guide.html#erasing-nonmain-for-mspm0), which makes that implementation not an issue there. Having not used pyocd, I'm not sure what might be equivalent in that interface, but from your description it seems pretty clear that its adding this algorithm on its own. 

David Summers said:

The underlying problem to my mind, is that the CMSIS-DAP Pack doesn't specify that doing a mass erase of NONMAIN  will brick the device, indeed it not clear to me how you could specify this. Maybe MSPM0G_NONMAIN.FLM should refuse to do a mass erase on NONMAIN, as on the MSPM0 devices you should never mass erase the area of memory - it make no sense. At best you may *very* occasionaly only write a few bits. [E.g. should the algorithm EraseSector and maybe EraseChip in MSPM0G_NONMAIN.FLM refuse to erase the NONMAIN memory error, and instead return status=1 so error - so only way to change bytes is the ProgramPage command, and erase is to write 0xff to a byte].

NONMAIN in the MSPM0 is actually only 512 bytes, so any erase operation to nonmain, which would need to be done before any programming, would erase the whole of NONMAIN (smallest erase resolution in MSPM0 is 1 sector).The BOOTCRC value in non-main must also be valid, so the expectation is that if programming any non-main at all, the programmer should know all the non-main values and reprogram them all to avoid locking the device due to invalid BOOTCRC.

David Summers said:

Now mass erase could have also been made safe by having the words that give access to the BSL and CMSIS-DAP port as 0xffff. Then any bit flit would still lock the device (which is the TI design requirement), but a mass erase would just leave the machine open - which doesn't seem to have any security holes. But TI chose another word that means leave CMSIS_DAP and BSL open.

I'm not sure if a scenario exists where only non-main could be erased, wherein having the higher access state be the erased state would be problematic. Either way, you're not the first person to give that feedback, internally or externally. It was ultimately decided that using a value such as 0xAABB or another value that is not all 1s or 0s is preferred from a security perspective, as its harder to glitch or create security holes when the value defining the less restrictive state is not all high or low. 

Ideally, we should only really have issues like the one you are seeing when there are problems with the tool chain or the description and use thereof, which unfortunately you've encountered when pairing our CMSIS-PACK with pyocd. 

Best Regards,
Brandon Fisher

Both Keil and pyocd evolved from mbed, which was an arm development for supporting arm devices, and supporting the devices from any manufacturer. CMSIS Pack I think also evolved from arm, so that is probably why Keil uses the CMSIS pack, and why its fairly good at describing what arm hardware looks like, and how to program it.

Pyocd when mbed moved on, became independent from arm, but I think the main people involved in it are all arm based. Pyocd is a python based on chip debugger, and being developed by arm its specifically for arm devices; unlike openocd which is far more general. Pyocd has a far more fiendly interface than openocd - openocd is very general, and horribly cryptic, it predates CMSIS Packs by probably 15 years! but now supports them I beleieve, I'm not sure how well. pyocd when developed was based on CMSIS packs - they are needed for the debugger to work - its how it knows what it is talking to.

Think my point was mainly becoming is does TI agree that its very hard to describe MSPM0 hardware in the CMSIS Pack, specifically that NONMAIN really should not be erased. Its how to say this in the Pack, there isn't really a method.

Yes you are probably right, that NONMAIN at only 512bytes needs a total erase to rewrite a single byte, but I guess the algorithms inside MSPM0G_NONMAIN.FLM know this, so when you use the ProgramPage command it knows how to do this. pyocd, I expect also knows that flash comes in sectors, and it need to understand this to know how to write a byte to a sector - I expect pyocd already has this right, as its now these flash devices work.

So problem with pyocd is when you try to do a chip erase, it takes an explicit command to do this, but when a command like that is run, pyocd does just that - erase the chip, as described in the CMSIS pack. Crux is as pyocd doesn't read documents, and just read the CMSIS pack, how should it be done.

Yes TI documentation, probably everywhere where you can do a chip erase (and there are many places you can do in) in the documentation does give a warning, that NONMAIN needs to be rewritten before a reset.

So think the question is does TI have anything to say? What I'll be doing is probably put a bug report into the CMSIS people @ arm that there probably needs to be a way to specific that a region of memory, although it is writable, this should be done very carefully. e.g. a chip erase is not a safe operation. CMSIS packs don't currently understand this, but its MSPM0 operation.

Hi David,

David Summers said:

Think my point was mainly becoming is does TI agree that its very hard to describe MSPM0 hardware in the CMSIS Pack, specifically that NONMAIN really should not be erased. Its how to say this in the Pack, there isn't really a method.

Based on what I've seen no, there's no way in the CMSIS-PACK to describe this in the programming algorithms. For Keil the default definition is enough. Based on this thread, our software team is adding pyocd compatibility to our list, so at some point they will have to take a stab at this anyway. For now I think the simplest workaround is to just remove the NONMAIN algorithm reference to prevent this. Its non-ideal, but it should function. 

David Summers said:

So think the question is does TI have anything to say? What I'll be doing is probably put a bug report into the CMSIS people @ arm that there probably needs to be a way to specific that a region of memory, although it is writable, this should be done very carefully. e.g. a chip erase is not a safe operation. CMSIS packs don't currently understand this, but its MSPM0 operation.

If you get any feedback on this in the meantime feel free to update this thread. At the moment the only way I can see this functioning is to workaround it kind of clumsily.

Best Regards,
Brandon Fisher