Mecrisp setup on TI MSP432 Launchpad

[Chris Curl]

So I got myself a TI MSP432 Launchpad for christmas.
The mecrisp page says it is supported MSP432P401R, which
I found in the download. The problem I have is that I
have not found specific (i.e. - step by step) instructions
how get mecrisp installed and running on this thing.

Any help or advice on how to get off the ground would be greatly
appreciated.

[rickman]

In the recent flurry of activity here I missed this post until now. I
feel your pain. Mecrisp is an interesting tool and supports a number of
platforms, but is not well documented by any means. But I believe there
are some installation instructions somewhere.

Without digging around for the instructions, I believe there is a file
in the Mecrisp package that is ready to be downloaded to the target.
You simply need to get your hands on a suitable installation tool to do
that. I recall that TI supplies a tool, but they do a poor job with the
Windows part and you need to use an unsigned driver which is a big PITA
under Windows 8 which I have. If you have an older version of Windows I
think using this driver is easier. I ended up using a driver for Linux
on a Raspberry Pi (rPi). The rPi worked so well for this that I ended
up using it as an interface for the Launchpad and worked on my PC
remotely.

My rPi is packed away at the moment, but it would not be too hard to
resurrect the steps I took to get it running. In fact, I want to
document this fully and make it available somewhere.

Have you tried searching on the web? I think I found everything I
needed that way. I may have exchanged some email with Matthais, but in
general his replies are not quick and I think he prefers not to get
bogged down in supporting each user. If you still can't find anything
I'll dig around to find the info I used.

--

Rick

[Jan Coombs]

On Sat, 2 Jan 2016 12:59:58 -0500
rickman <gnu...@gmail.com> wrote:
[snipped]

As Rick says, you need the mecrisp-stellaris image file, and a
tool to upload this to your micro. The NXP ARM I installed this
on was easy, both using a NXP tool for windows and a command
line tool for linux.

I couldn't find TI tools on their site, but found this:

http://energia.nu/

I'm not sure how close this development is to TI, but it says it
is open source. It is a complete IDE, so whether you can find
the uploader or build it quickly as a standalone I couldn't
figure.

If all else fails get a $8? DIL28 NXP part and do initial
mecrisp-stellaris install on that.

Jan Coombs.

[Paul Rubin]

Jan Coombs <jenfhaom...@murmic.plus.com> writes:
> If all else fails get a $8? DIL28 NXP part and do initial
> mecrisp-stellaris install on that.

Might be easier to just get a Stellaris (Kiva) Launchpad. But it
would be nice to run Mecrisp on the MSP432 Launchpad.

Flashforth also seems really nice, and Mikael has been posting here
lately. I'm not sure which (if any) of these boards it runs on, though.

[Matthias Koch]

> I couldn't find TI tools on their site, but found this:
>
> http://energia.nu/
>
> I'm not sure how close this development is to TI, but it says it
> is open source. It is a complete IDE, so whether you can find
> the uploader or build it quickly as a standalone I couldn't
> figure.

Exactly. Flashing instructions are in the README file in
the main directory of Mecrisp-Stellaris, and you can use
the tool supplied with recent Energia for Linux.

Matthias


;------------------------------------------------------------------------------
Hardware and configuration for MSP432P401R:
;------------------------------------------------------------------------------
Connect your cable to the USB-Port,
set "JTAG switch" to XDS position,
close 5V, 3V3, RXD, TXD jumpers.

Flashing is possible with DSLite, which is part of Energia 15:
DSLite -c MSP432P401R.ccxml -f mecrisp-stellaris-msp432p401r.bin -l 0

On startup, this runs with DCO on 12 MHz.

[Chris Curl]

Thanks for all your responses. With the holidays, things have been
kind of busy. Now that things have settled down a little, I hope to
get this thing up and running this week.

Thanks for the pointers.

I am on a Windows 10 system. This evening after work, I'll see if I
can find and install this Energia system for that DSLite program.

[Matthias Koch]

Up and running now ?
Matthias

[Chris Curl]

On Thursday, January 14, 2016 at 6:22:04 AM UTC-5, Matthias Koch wrote:
> Up and running now ?
> Matthias

Thanks for asking! Alas, other priorities have cropped up that have been taking my attention.
My son is on winter break, and he bought a kit to build an API compatible audio compressor
which I have been helping him put together. I am also working on putting together a slide
show for a celebration of my late mother's life next week.

But believe me when I say that I am extremely interested in making this happen, so this
will not be on the back burner for long.

[dalesc...@gmail.com]

I was very excited to find the Mecrisp project, and that the MSP432 Launchpad is supported. I cannot load the bin file as indicated though in the README. First, it seems DSLite parameters have changed since Energia 15 Fwiw, I had the same error with Energia 17 before trying Energia 18, and also fyi I'm on Windows 10. I will try Energia 15 next, but I'm posting this now because I would prefer to use the latest version of Energia.

It was not clear from README if I should be using the bin file in the \msp432p401r directory, or the \msp432p401r-ra directory. Which is correct?

For Energia 17 and 18, I had to add "load" to the provided DSLite command line (I also had to find MSP432P401R.ccxml in the Energia distribution, and copied it to the same directory as the bin file). However, DSLite then reported an error with the file type. Fwiw, it seems from Google that DSLite typically loads ELF files, but "DSLite load" indicates that binary files can also be loaded.

C:\work\mecrisp-stellaris-2.3.3\msp432p401r-ra>C:\energia-1.6.10E18\hardware\tools\DSLite\DebugServer\bin\DSLite.exe load -c .\MSP
_EXP432P401R.ccxml -f mecrisp-stellaris-msp432p401r.bin -l log.txt
DSLite version 6.2.1.1595
Configuring Debugger (may take a few minutes on first launch)...
Initializing Register Database...
Initializing: CS_DAP_0
Executing Startup Scripts: CS_DAP_0
Initializing: CORTEX_M4_0
Executing Startup Scripts: CORTEX_M4_0
Connecting...
GEL: CORTEX_M4_0: GEL Output: Memory Map Initialization Complete
GEL: CORTEX_M4_0: GEL Output: Halting Watchdog Timer
Failed: Encountered a problem loading file: mecrisp-stellaris-msp432p401r.bin
Could not determine target type of file

C:\work\mecrisp-stellaris-2.3.3\msp432p401r-ra>

Can anyone load mecrisp on an MSP432 LaundhPad? I would really appreciate some direction.

Thanks!
Dale

[dalesc...@gmail.com]

On Friday, 20 January 2017 18:56:55 UTC-7, dalesc...@gmail.com wrote:
>...

> I will try Energia 15 next, but I'm posting this now because I would prefer to use the latest version of Energia.
>
> It was not clear from README if I should be using the bin file in the \msp432p401r directory, or the \msp432p401r-ra directory. Which is correct?

>...

I have confirmed the version of DSLite included in Energia 15 appears to work using the listed command line in the Mecrisp-Stellaris README (and only the version included in Energia 15). However, DSLite now reports incompatible firmware in the XDS110 debug probe (part of the LaunchPad). I followed the directions to update the XDS110 firmware to latest (using the firmware file included in Code Composer Studio) with no effect, so I suspect I need to actually downgrade the XDS110 firmware.

Does anyone know if this is correct, and if so, where I can get a firmware.bin file from the Energia 15 era? Also fwiw, I'm using the ccxml file from the version of Energia I'm using DSLite from, e.g. MSP4
32P401R.ccxml from Energia 15 (I added the prefix for clarity as I was copying them into the Mecrisp-Stellaris msp432P4014r\ directory with the Mecrisp-Stellaris .bin file).

Also, I'm still unsure if I should be using the Mecrisp bin file from the \msp432p401r directory, or the \msp432p401r-ra directory. Can anyone clarify?

Cheers!
Dale

C:\work\mecrisp-stellaris-2.3.3\msp432p401r>C:\energia-0101E0015\tools\common\DSLite\DebugServer\bin\DSLite.exe load -c .\r15_MSP4
32P401R.ccxml -f mecrisp-stellaris-msp432p401r.bin -l log.txt
Initializing debug probe...
Configuring Debugger (may take a few minutes on first launch)...:
Parsing connections/TIXDS110_Connection.xml
Parsing drivers/tixds510cs_dap.xml
Parsing drivers/tixds510cortexM.xml
Parsing devices/msp432p401r.xml
<snip>
Parsing ../Modules/MSP432/tpiu.xml
Parsing ../Modules/MSP432/wdt_a.xml
Parsing ../Modules/MSP432/MSP432_JSTATE_2_NotVisible.xml
Initializing Register Database...
Parsing C:\Users\dale\AppData\Local\TEXASI~1\CCS\tools\2\0\232622502.cache
Initializing: CS_DAP_0
Mapping registers: CS_DAP_0 - Core Registers
Mapping registers: CS_DAP_0 - Hidden
Building search data: CS_DAP_0

Executing Startup Scripts: CS_DAP_0
Initializing: CORTEX_M4_0

Mapping registers: CORTEX_M4_0 - Core Registers
Mapping registers: CORTEX_M4_0 - ADC14
Mapping registers: CORTEX_M4_0 - AES256
<snip>
Mapping registers: CORTEX_M4_0 - TLV
Mapping registers: CORTEX_M4_0 - TPIU
Mapping registers: CORTEX_M4_0 - WDT_A
Mapping registers: CORTEX_M4_0 - Hidden
Building search data: CORTEX_M4_0

Executing Startup Scripts: CORTEX_M4_0
Connecting...

Fatal: CS_DAP_0: Error connecting to the target: (Error -263 @ 0x0) Incompatible XDS110 firmware detected. The firmware v
ersion of the connected XDS110 debug probe does not match the expected version. Please update the firmware using the xdsdfu util
ity found in the .../ccs_base/common/uscif/xds110 directory of your installation. View the ReadMe.txt file there for instruction
s. (Emulation package 0.0.0.0)
Failed: Failed to evaluate GEL_Connect(): Connect failed

C:\work\mecrisp-stellaris-2.3.3\msp432p401r>

[Matthias Koch]

Hi Dale,

I am the author of Mecrisp and Mecrisp-Stellaris. Yes, comp.lang.forth is one of the places I occassionally look at. Most new Mecrisp-Stellaris users just write an E-Mail to me, and there are two places where users of Mecrisp-Stellaris meet: The Jeelabs-Forums on http://jeelabs.org/ and experimental developers on https://github.com/jeelabs/mecrisp-stellaris

If you wish an open source Forth on your MSP432 Launchpad, go for Mecrisp-Stellaris, I am not aware of another one. If you wish a commercial solution, you are already in contact with Stephen and Elisabeth, who offer you the Forth cross compilers VFX and SwiftX.

The MSP432 registers feel like a nice design combining MSP430 peripherals with an ARM processor, but unfortunately, the tools for flashing it are a nightmare. You can use any flashing tool to write the bin file to the chip, but finding a tool that works on your system can be difficult. I just documented the way I managed to flash my MSP432 Launchpad. All I can offer you is: Good luck !

> Also, I'm still unsure if I should be using the Mecrisp bin file from the \msp432p401r directory, or the \msp432p401r-ra directory. Can anyone clarify?

Yes, of course. The one in /msp432p401 is smaller and does constant folding for optimisation, the variant in /msp432p401r-ra is 4 kb larger, but also gives you an register allocator algorithm, which generates faster machine code. The choice is yours, both look and feel exactly the same. It is just that some people prefer a smaller core, others prefer stronger optimisations.

Best wishes from Germany,
Matthias

[Dale Scott]

Thanks Matthias for your clarifications and encouragement. All things being equal, I would prefer an open-source toolset over a proprietary one, and I hope I can solve the loading problem. I am using the same LaunchPad as you, but it seems the loader DSLite.exe and the debug probe firmware on the LaunchPad have diverged since you found your solution. I also read that TI CCS is able to load a binary file to a target via the debug probe, but the menu item seems to have moved. I will post to JeeLabs and perhaps someone has a solution already.

[Albert van der Horst]

In article <o64tof$ur5$1...@news.luis.uni-hannover.de>,

Matthias Koch <matthi...@hot.uni-hannover.de> wrote:
>Hi Dale,
>
>I am the author of Mecrisp and Mecrisp-Stellaris. Yes, comp.lang.forth is one of the places I occassionally look at. Most new Mecrisp-Stellaris users just write an E-Mail to me, and there are two places where users of Mecrisp-Stellaris meet: The Jeelabs-Forums on http://jeelabs.org/ and experimental developers on https://github.com/jeelabs/mecrisp-stellaris

Please restict your lines to 72 char's

>
>If you wish an open source Forth on your MSP432 Launchpad, go for Mecrisp-Stellaris, I am not aware of another one. If you wish a commercial solution, you are already in contact with Stephen and Elisabeth, who offer you the Forth cross compilers VFX and SwiftX.
>
>The MSP432 registers feel like a nice design combining MSP430
>peripherals with an ARM processor, but unfortunately, the tools for
>flashing it are a nightmare. You can use any flashing tool to write
>the bin file to the chip, but finding a tool that works on your system
>can be difficult. I just documented the way I managed to flash my
>MSP432 Launchpad. All I can offer you is: Good luck !

I've managed to calibrate the msp430, i.e. set the clock speed.
This is done via a small program in ram. Willem Ouwerkerk is attempting
a new technique to flash those msp430: write our own monitor, put it
in Ram, then use that. The advantage is that the instructions are much
easier, because it is missing useless features, and it is
"one size fits all".
I can then flash about any msp430, via a 4 bit interface on the parallel
port.

Now they have a new hurdle, TI wants a crc. They throw a zillion documents
at you except the exact definition of which crc.

If someone can help out with reproducing crc16:
crc-16 crc-16 crc-16 crc-16
polynomial $8005 $8005 $4C11DB7 $4C11DB7
init CRC register $0 $0 $0 $0
Final XOR value $0 $0 $0 $0
Reflect data (byte) NO YES NO YES
Reflect Crc (word) NO YES NO YES
input "123456789" "123456789" "123456789" "123456789"
Expected CRC $FEE8 $BB3D $FEE8 $BB3D

The combination input/output is the only real straw we can grasp.

The problem is that there is no connection to be found between the terms
used by TI in the first column and the general theory.

<SNIP>

>
>Best wishes from Germany,
>Matthias

Groetjes Albert
--
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[Howerd]

On Tuesday, January 24, 2017 at 1:08:01 PM UTC+1, Albert van der Horst wrote:
> In article <o6.luis.uni-hannover.de>,

Hi Albert,

It all seems very confusing...

The second column appears to be the Modbus CRC16 with the init and exit XOR values set to 0 instead of -1 .

The Modbus CRC16 code is here : http://www.inventio.co.uk/crc16modbus.f
Change the code as follows :
\ initialises the input CRC value in the required way
: initIncomingCRC 0 incomingCRC w! ; \ was -1 for Modbus

\ initialises the output CRC value in the required way
: initOutgoingCRC 0 outgoingCRC w! ; \ was -1 for Modbus

This gives $BB3D from "123456789".

Probably column 1 is the same but with all data bit-reversed and the final CRC bit-reversed too.

Columns 3 and 4 are strange because they seem to have 32 bit polynomials which I have never seen...

I will post the modified Texas Instruments code, when I get FTP access, here :
http://www.inventio.co.uk/crc16texas.f

I hope this helps :-)

Best regards
Howerd

[Mark Wills]

Here's a MODBUS CRC routine I wrote a few years back that doesn't
need a lookup table. I was using it as a primitive hashing algorithm
hence it's called >HASH ("to hash") but it's the plain old MODBUS CRC.

It's taken from here: http://turboforth.net/resources/locals.html

Back to lurking :-)

: >HASH ( c-addr len -- u)
\ hashes a string using the CRC-16 algorithm
$FFFF \ initial CRC16
-ROT \ move it out of the way
OVER + SWAP DO \ for each byte in the string
I C@ XOR \ xor with CRC16
8 0 DO \ for 8 bits in the byte
DUP 1 AND \ note the LSB prior to shift
SWAP 1 >> \ shift the CRC16
SWAP IF
$A001 XOR \ if LSB was 1 then apply polynomial
THEN
LOOP
LOOP ;

[Albert van der Horst]

In article <58783373-560b-4984...@googlegroups.com>,
Howerd <how...@yahoo.co.uk> wrote:
>On Tuesday, January 24, 2017 at 1:08:01 PM UTC+1, Albert van der Horst wrot=
<SNIP>
>>=20
>> Now they have a new hurdle, TI wants a crc. They throw a zillion document=

>s
>> at you except the exact definition of which crc.

>>=20

>> If someone can help out with reproducing crc16:
>> crc-16 crc-16 crc-16 crc-16

>> polynomial $8005 $8005 $4C11DB7 $4C11=

>DB7
>> init CRC register $0 $0 $0 $0
>> Final XOR value $0 $0 $0 $0
>> Reflect data (byte) NO YES NO YES
>> Reflect Crc (word) NO YES NO YES

>> input "123456789" "123456789" "123456789" "1234=

>56789"
>> Expected CRC $FEE8 $BB3D $FEE8 $BB3D

>>=20

>> The combination input/output is the only real straw we can grasp.

>>=20

>> The problem is that there is no connection to be found between the terms
>> used by TI in the first column and the general theory.

>>=20

>> <SNIP>
>> >
>> >Best wishes from Germany,
>> >Matthias

>>=20
>> Groetjes Albert
>> --=20

>> Albert van der Horst, UTRECHT,THE NETHERLANDS
>> Economic growth -- being exponential -- ultimately falters.

>> albert@spe&ar&c.xs4all.nl &=3Dn http://home.hccnet.nl/a.w.m.van.der.horst

>
>Hi Albert,
>
>It all seems very confusing...
>

>The second column appears to be the Modbus CRC16 with the init and exit XOR=

> values set to 0 instead of -1 .
>
>The Modbus CRC16 code is here : http://www.inventio.co.uk/crc16modbus.f
>Change the code as follows :
>\ initialises the input CRC value in the required way
>: initIncomingCRC 0 incomingCRC w! ; \ was -1 for Modbus

> =20

>\ initialises the output CRC value in the required way
>: initOutgoingCRC 0 outgoingCRC w! ; \ was -1 for Modbus
>
>This gives $BB3D from "123456789".
>

>Probably column 1 is the same but with all data bit-reversed and the final =
>CRC bit-reversed too.

Once the bit-reversal idea sinks in, I can reproduce column 2 with

\ ---------------------- 8< -----------------------------
"BOUNDS" WANTED
":NONAME" WANTED

1 CELLS 4 <> 1001 ?ERROR

HEX
: reverse-bits
0 SWAP 10 0 DO
DUP 1 AND ROT 1 LSHIFT OR SWAP 1 RSHIFT
LOOP DROP ;
\ REGRESS FF00 reverse-bits S: 00FF
\ REGRESS 8005 reverse-bits S: A001

\ Well the polynomial
8005 reverse-bits CONSTANT CRC16_POLYNOMIAL
\ Auxiliary table with values for single bytes.
:NONAME
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC16_POLYNOMIAL XOR THEN
LOOP 0FFFF AND , LOOP
; CREATE CRCTable EXECUTE
\ For initial CRC and BUFFER COUNT pair, leave the updated CRC
: CRC-MORE BOUNDS DO DUP I C@ XOR 0FF AND CELLS CRCTable + @
SWAP 8 RSHIFT XOR LOOP ;
\ For BUFFER COUNT pair, leave the CRC .
: CRC -1 ROT ROT CRC-MORE INVERT ;

: CRC-16B 0 ROT ROT CRC-MORE ;
\ REGRESS "123456789" CRC-16B S: 0 BB3D

\ ---------------- 8< ---------------------------

Notes:
1. reverse-bits only works reversing 16 bits on a 32 bit Forth.
2. REGRESS signals a test (failure aborts on ciforth)
3. The :NONAME generates the aux table at compile time.
On ciforth this is more elegant, as it can execute loops
in interpret mode.

The compact version for ciforth is a one screener:
\ ---------------------- 8< -----------------------------
WANT BOUNDS HEX
\ Well the polynomial
A001 CONSTANT CRC16_POLYNOMIAL

CREATE CRCTable \ Auxiliary table with values for single bytes.
100 0 DO I 8 0 DO
DUP >R 1 RSHIFT R> 1 AND IF CRC16_POLYNOMIAL XOR THEN
LOOP 0FFFF AND , LOOP

\ For initial CRC and BUFFER COUNT pair, leave the updated CRC
: CRC-MORE BOUNDS DO DUP I C@ XOR 0FF AND CELLS CRCTable + @
SWAP 8 RSHIFT XOR LOOP ;

\ For BUFFER COUNT pair, leave the CRC .
: CRC-16B 0 ROT ROT CRC-MORE ;
DECIMAL
\ ---------------- 8< ---------------------------

>
>Columns 3 and 4 are strange because they seem to have 32 bit polynomials wh=

>ich I have never seen...

I can reproduce column 4 with the built in crc of ciforth.
The polynomial is the bit-reversal of the polynomial represented by
$EDB8,8320

>
>I will post the modified Texas Instruments code, when I get FTP access, her=
>e :=20

>http://www.inventio.co.uk/crc16texas.f
>
>I hope this helps :-)

Certainly. I hope you like the idea of calculating the table at compile
time, something that you could not do in C.

>
>Best regards
>Howerd

[Mark Wills]

Note: The word >> is a right shift in my Forth system.

Regards

Mark

[Albert van der Horst]

In article <7bd0c18a-4305-4f42...@googlegroups.com>,

Mark Wills <markwi...@gmail.com> wrote:
>On Wednesday, 25 January 2017 12:43:37 UTC, Howerd wrote:

>> On Tuesday, January 24, 2017 at 1:08:01 PM UTC+1, Albert van der Horst wr=

>ote:
>> > In article <o6.luis.uni-hannover.de>,
>> > Matthias Koch <matthia.uni-hannover.de> wrote:
>> > >Hi Dale,
>> > >

>> > >I am the author of Mecrisp and Mecrisp-Stellaris. Yes, comp.lang.forth=
> is one of the places I occassionally look at. Most new Mecrisp-Stellaris u=
>sers just write an E-Mail to me, and there are two places where users of Me=
>crisp-Stellaris meet: The Jeelabs-Forums on http://jeelabs.org/ and experim=

>ental developers on https://github.com/jeelabs/mecrisp-stellaris
>> > Please restict your lines to 72 char's

>> >=20
>> > >
>> > >If you wish an open source Forth on your MSP432 Launchpad, go for Mecr=
>isp-Stellaris, I am not aware of another one. If you wish a commercial solu=
>tion, you are already in contact with Stephen and Elisabeth, who offer you =

>the Forth cross compilers VFX and SwiftX.
>> > >
>> > >The MSP432 registers feel like a nice design combining MSP430
>> > >peripherals with an ARM processor, but unfortunately, the tools for
>> > >flashing it are a nightmare. You can use any flashing tool to write
>> > >the bin file to the chip, but finding a tool that works on your system
>> > >can be difficult. I just documented the way I managed to flash my
>> > >MSP432 Launchpad. All I can offer you is: Good luck !

>> >=20

>> > I've managed to calibrate the msp430, i.e. set the clock speed.
>> > This is done via a small program in ram. Willem Ouwerkerk is attempting
>> > a new technique to flash those msp430: write our own monitor, put it
>> > in Ram, then use that. The advantage is that the instructions are much
>> > easier, because it is missing useless features, and it is
>> > "one size fits all".

>> > I can then flash about any msp430, via a 4 bit interface on the paralle=
>l
>> > port.
>> >=20
>> > Now they have a new hurdle, TI wants a crc. They throw a zillion docume=

>nts
>> > at you except the exact definition of which crc.

>> >=20

>> > If someone can help out with reproducing crc16:

>> > crc-16 crc-16 crc-16 crc-=
>16
>> > polynomial $8005 $8005 $4C11DB7 $4C=

>11DB7
>> > init CRC register $0 $0 $0 $0
>> > Final XOR value $0 $0 $0 $0
>> > Reflect data (byte) NO YES NO YES
>> > Reflect Crc (word) NO YES NO YES

>> > input "123456789" "123456789" "123456789" "12=
>3456789"
>> > Expected CRC $FEE8 $BB3D $FEE8 $BB=
>3D
>> >=20

>> > The combination input/output is the only real straw we can grasp.

>> >=20
>> > The problem is that there is no connection to be found between the term=

>s
>> > used by TI in the first column and the general theory.

>> >=20

>> > <SNIP>
>> > >
>> > >Best wishes from Germany,
>> > >Matthias

>> >=20
>> > Groetjes Albert
>> > --=20

>> > Albert van der Horst, UTRECHT,THE NETHERLANDS
>> > Economic growth -- being exponential -- ultimately falters.

>> > albert@spe&ar&c.xs4all.nl &=3Dn http://home.hccnet.nl/a.w.m.van.der.hor=
>st
>>=20
>> Hi Albert,
>>=20

>> It all seems very confusing...

>>=20
>> The second column appears to be the Modbus CRC16 with the init and exit X=

>OR values set to 0 instead of -1 .

>>=20

>> The Modbus CRC16 code is here : http://www.inventio.co.uk/crc16modbus.f
>> Change the code as follows :
>> \ initialises the input CRC value in the required way
>> : initIncomingCRC 0 incomingCRC w! ; \ was -1 for Modbus

>> =20

>> \ initialises the output CRC value in the required way
>> : initOutgoingCRC 0 outgoingCRC w! ; \ was -1 for Modbus

>>=20

>> This gives $BB3D from "123456789".

>>=20
>> Probably column 1 is the same but with all data bit-reversed and the fina=
>l CRC bit-reversed too.
>>=20
>> Columns 3 and 4 are strange because they seem to have 32 bit polynomials =

>which I have never seen...

>>=20
>> I will post the modified Texas Instruments code, when I get FTP access, h=
>ere :=20
>> http://www.inventio.co.uk/crc16texas.f
>>=20

>> I hope this helps :-)

>>=20

>> Best regards
>> Howerd
>
>Here's a MODBUS CRC routine I wrote a few years back that doesn't
>need a lookup table. I was using it as a primitive hashing algorithm
>hence it's called >HASH ("to hash") but it's the plain old MODBUS CRC.
>
>It's taken from here: http://turboforth.net/resources/locals.html
>
>Back to lurking :-)
>
>: >HASH ( c-addr len -- u)
> \ hashes a string using the CRC-16 algorithm
> $FFFF \ initial CRC16
> -ROT \ move it out of the way
> OVER + SWAP DO \ for each byte in the string
> I C@ XOR \ xor with CRC16
> 8 0 DO \ for 8 bits in the byte
> DUP 1 AND \ note the LSB prior to shift
> SWAP 1 >> \ shift the CRC16

> SWAP IF=20

> $A001 XOR \ if LSB was 1 then apply polynomial

> THEN =20
> LOOP
> LOOP ;

This doesn't reproduce column 2.

"123456789" >HASH H.
0000,4B37 OK

Remember the problem never was to have "a" crc, but how TI uses it.
You site is nice though.

[Howerd]

On Wednesday, January 25, 2017 at 3:23:46 PM UTC+1, Albert van der Horst wrote:
> In article <7bd0c18a-4305-4f42-8eca-f16d89f4ef91>,

> Mark Wills <markwills1970> wrote:
> >On Wednesday, 25 January 2017 12:43:37 UTC, Howerd wrote:
> >> On Tuesday, January 24, 2017 at 1:08:01 PM UTC+1, Albert van der Horst wr=

[snip for readability]

Hi Albert,

Mark's CRC16 is proper Modbus - the TI version starts with a $0000 rather than $FFFF.
Below is a slightly ANSified version ( >> is renamed to rshift ).
It runs and gives the correct answer if dropped into SwiftForth.

Liebe Gruesse,
Howerd

: >HASH ( c-addr len -- u)
\ hashes a string using the CRC-16 algorithm

$0000 \ initial CRC16

-ROT \ move it out of the way
OVER + SWAP DO \ for each byte in the string
I C@ XOR \ xor with CRC16
8 0 DO \ for 8 bits in the byte
DUP 1 AND \ note the LSB prior to shift

SWAP 1 rshift \ shift the CRC16
SWAP IF

$A001 XOR \ if LSB was 1 then apply polynomial
THEN

LOOP
LOOP ;

: ttmwcrc16 ( -- ) s" 123456789" >HASH hex u. ;

ttmwcrc16

[hard...@darcygirl.com]

>
> Can anyone load mecrisp on an MSP432 LaundhPad? I would really appreciate some direction.
>

FWIW Under Linux, I was able to load mecrisp on an old black MSP432 Launchpad (Revision B silicon) using DSLite from energia-1.6.10E18 by converting the .bin file to a .elf file using objcopy

$ arm-none-eabi-objcopy -I binary -O elf32-littlearm --binary-architecture arm mecrisp-stellaris-msp432p401r.bin mecrisp-stellaris-msp432p401r.o

The DSLite command was:
$ sudo ./DebugServer/bin/DSLite load -c MSP_EXP432P401R.ccxml -f mecrisp-stellaris-msp432p401r.o

This was with both the original and newer XDS firmware.
The original was 2.2.4.0 and the newer 2.3.0.9

$ sudo ./xdsdfu -m

USB Device Firmware Upgrade Utility
Copyright (c) 2008-2015 Texas Instruments Incorporated. All rights reserved.

Scanning USB buses for supported XDS110 devices...


<<<< Device 0 >>>>

VID: 0x0451 PID: 0xbef3
Device Name: XDS110 with CMSIS-DAP
Version: 2.2.4.0
Manufacturer: Texas Instruments
Serial Num: 00000000
Mode: Runtime

Switching device into DFU mode.


Hopefully, this helps someone out in the future.

Eric

[rickman]

The trick is always finding the info.

--

Rick C