Running EK-TM4C123GXL (or similar) bootloader on Mini-M4 Tiva board

Hello Jake

The EK-TM4C123GXL does not have any preinstalled boot loader. What you are using and seeing is the device's ROM boot loader which is standard for all TM4C devices irrespective of the board they are on.

However on the EK-TM4C123GXL there is a ICDI chip which emulates UART over USB allowing you to download via the USB cable an image, and I am not sure how mini-M4 does that for which you would need to check with the manufacturer.

Regards
Amit

Your selection of, "Multi-Vendor" product renders you vulnerable to such issues.

The "other" vendor may not be overly interested in assisting your move (away) from their proprietary "BL" method as that (likely) "locks" users to that board...

Never hurts to inquire (further) of that "other" vendor - note how generous Amit has been in responding -  and attempting to guide you to some solution...

Amit Ashara said:

However on the EK-TM4C123GXL there is a ICDI chip which emulates UART over USB allowing you to download via the USB cable an image, and I am not sure how mini-M4 does that for which you would need to check with the manufacturer.

From the available information on the mini-M4 there is no equivalent of the ICDI, since the only ICs on the mini-M4 board are the TM4C123GH6PM and a voltage regulator. The TM4C123GH6PM USB is used for connection to the bootloader.

This means the TM4C123GH6PM on the mini-M4 must be programmed with a MikroElektronika USB HID custom bootloader. The hex image for the MikroElektronika USB HID bootloader is available, but not the source code.

Jake Ernst said:

Also, I have tried flashing some of my existing .hex images (complied for the TM4C123GH6PM) to the board. MikroBootloader immediately returns success, but the program I flash does not run (although I am able to load MikroElectronica's supplied demo programs with no issue).

Given that the USB HID bootloader appears to be programmed in user flash, a user program must be relocated to a different area of flash.

However, from looking at the MikroElectronica documentation for the mini M4 I can't see where it is defined the flash location to be used for a user program. The MikroElectronica example programs are written for the MikroElectronica compilers, and the example programs don't seem to define the memory layout.

I think you will need to ask MikroElectronica about how to write a program with a different compiler for use with the MikroElectronica USB HID bootloader.

Failing that, another option would be not use the MikroElectronica USB HID bootloader, and instead connect a JTAG emulator.

Chester Gillon said:

think you will need to ask MikroElectronica about how to write a program with a different compiler for use with the MikroElectronica USB HID bootloader.

At the price point of that board - and (that) firm's (seeming) intent to "lock-in" users - their motivation for providing (meaningful, "different compiler") assistance appears minimal...    Still - as you've repeated - poster (should) make the effort.  

Should poster's goal be reduced board size/cost (when compared to LPad) - Amit's direction seems most likely, "road to success."

Thank you everyone for your responses.

Amit,

I was definitely missing the ICDI chip on the board. That is not included on the Mini-M4 board. Thank you for pointing that out. Let me also mention that I do not plan on leaving your product line. TI's Launchpad boards have been instrumental in my development and learning, and I've been using code composer studio heavily.

Chester,

Yes, it feels very much like MikroElectronica is trying to lock into a proprietary implementation. And yes, I have their windows HID application, example source, and bootloader hex (with no source).

I am interested in perusing loading over JTAG on the Launchpad board anyway, so I think that is my next step.

Hello Jake

Thank you for the kind words. There are a lot of vendors that do custom development platforms and have their own USB HID boot loaders. While these may seem like problematic, the presence of the boot strap loaders may actually be useful like in preventing a device lock out by building in protection over the device. At the same time the use of such systems makes the end system vendor "unspecific" allowing engineers to work across multiple platforms.

JTAG is a good choice if you wish to use vanilla systems. I would advise a XDS100v2.

Regards
Amit

Yes, it feels very much like MikroElectronica is trying to lock into a proprietary implementation. And yes, I have their windows HID application, example source, and bootloader hex (with no source).

I would not really call it "lock in". Albeit there is no "debug adapter" (like ICDI) on-board, all the relevant debug pins of the MCU are conveniently available on connector pins. You can connect an external debug pod, and, as a first step, erase the MikroE custom bootloader. The latter is probably a convenience under the (IMHO overpriced) MikroE toolchain, but near-to-worthless everywhere else.

I have a Mini-M0 with a STM32F051, and erasing this bootloader was one of my very first thing I did. Ever since worked without problems.

I actually was able to use the provided JTAG pins on the EK-TM4C123GXL to load the other board directly. That's a hugely convenient functionality.

Hello Jake,

Well that is possible with the LaunchPads as long as the other side device is a TM4C

Regards
Amit

if one erases the custom bootloader, is it necessary to reflash another one to let the mcu still boot properly? From Yiu's 'The Definitive Guide to ARM' FIGURE 7.12 I presume that for the booting magic to happen then you still need a bootloader on board. Is that so? I seem to be missing a piece(s) of the puzzle. I use a j-link edu with the mini-m4, so I really do not care about the custom bootloader USB functionality.

As a matter of curiosity - and also to "speed & ease" your development - is the added: time, effort & complexity/uncertainty wrought by the boot-loader - necessary at this time?

As you note - your J-Link edu (same as my firm's (official) ones) is quite capable of program & debug - and avoids ALL of the grief which proves, "Standard Part" of "boot-load brigade."

Note that never/ever is the "justification" for the (vital?) boot-loader supplied....

my context is that of a curious hobbyist. Last week I realized that either on my tiva c and mini-m4 my in-house assembled toolchain is always leaving .text in flash. Decided that I want to try moving it to RAM just to see if in the scope I detect any change in my figures measurements.

In my linker script I moved .text to RAM but nothing worked. For starters, I realized later on, that I need to actually copy .text from flash to RAM first myself. And then I got confused thinking that somehow the bootloader also needs to 'know' about all this.

It seems now to me, from your reply and additional reading (data sheet 8.2.2.1), that by using a jtag (well, swd) programmer the bootloader is really, and completely, out of the picture. Running from RAM just take copying .text to RAM. I have not tried that yet.

My final objective is to be able to, using openocd, 'flash' the tiva and mini to RAM and run from there. Programming to flash will be necessary only after my development is ready (never?). That final code would need to copy itself into RAM before running.

I still feel enough confused as to close asking an actual question.

I see NO advantage to your employing the boot-loader under the usage & desires you express.

An additional "layer of complexity" is added - and as always - little (i.e. NO) justification for the boot-loader is presented.

SWD via J-Link is the standard program/debug mode used by my (small) firm and ALL of the "giants" for whom we are fortunate to serve. J-Link attachment "avoids/escapes" ALL of the (unnecessary hoop-jumping & complexity) of the vaunted (yet always unjustified) boot-loader!