TI has two new Hercules LaunchPads

[abecedarian 330]

http://www.ti.com/tool/LAUNCHXL2-TMS57012

- automotive qualified

 

http://www.ti.com/tool/LAUNCHXL2-RM46

- industrial / medical oriented

[spirilis 1,265]

Lol wow, I guess the TMS570's price is a mistake... I saw the marketing stuff about these new chips (from their FB and twitter feeds) but didn't think they'd make launchpads for them. Now I wonder if we'll see a new C2000 LaunchPad for their F2807x series that they're pimpin

[spirilis 1,265]

Looks like they're using dual 40-pin BoosterPack pinouts, and substantially improved CPU specs - 180MHz for TMS570, 220MHz for RM46.  This is now the fastest LaunchPad out there, eclipsing the TM4C129 by far (Cortex-R4 is more efficient than Cortex-M4 anyhow) and it's R4F, not R4 like the older Hercules LP's.

 

But still locked into the Hercules dev tools (HALCoGen + CCS) of course, so it's only worth it if you need that kind of horsepower for something specific where you're willing to use that HALCoGen+CCS toolchain.  i.e. Energia won't ever run on these :-P

[spirilis 1,265]

Cool feature available on the BGA is the EMIF - External Memory Interface ... but sadly that's not available on the 144-LQFP package of the chip, which is what the LaunchPad uses.  Not going to buy one of these personally, but it's neat since it seems like such a high-end MCU option for the LaunchPad ecosystem.

[GrumpyOldPizza 15]

I am tempted to use the LAUNCHXL2-RM46 for some rover tinkering. It had a lot of FLASH/RAM, and double precision floating point. But it has this utterly useless VIM as interrupt controller. Why couldn't they just use a GIC with interupt priority levels and priority masking ...

[abecedarian 330]

I am tempted to use the LAUNCHXL2-RM46 for some rover tinkering. It had a lot of FLASH/RAM, and double precision floating point. But it has this utterly useless VIM as interrupt controller. Why couldn't they just use a GIC with interupt priority levels and priority masking ...

Because these devices are meant to be "fail safe", so a generic interrupt controller wouldn't satisfy that, maybe?

 

You could write your own interrupt control routines which could, within themselves, mask and / or prioritize things to your liking.

[GrumpyOldPizza 15]

Because these devices are meant to be "fail safe", so a generic interrupt controller wouldn't satisfy that, maybe?

 

You could write your own interrupt control routines which could, within themselves, mask and / or prioritize things to your liking.

 

The 2 cores are in lockstep. I'd assume that the interrupts would get broadcasted properly.

 

Doing this by hand as you suggested adds a huge overhead to the ISR shell. I did that ages ago for a ARMV4t device with a VIC, and there the cost was about 20 clock cycles on entry and an exit. That device had only 32 IRQs, hence less registers to touch.

[abecedarian 330]

@@BizzaBoy

 

Yes, the two cores are 'lockstep', as in both run the same code, one a clock or two behind the other, and both are passed the same values from ISR and such. This is the nature of 'safety' things, where things are double-checked, and any error throws a fault.

 

I'd argue that any error or event that warrants processor attention needs addressed regardless how many clock cycles are involved; that is the nature of safety, no?

 

Tedious as it may be, the architecture forces you to consider, and deal with, most every possible fault / failure.

 

I'd also consider the differences between ARMv4, which you seem to be familiar with, and ARMv7, which is what the R4F cores are more closely related to.

[GrumpyOldPizza 15]

@@BizzaBoy

 

Yes, the two cores are 'lockstep', as in both run the same code, one a clock or two behind the other, and both are passed the same values from ISR and such. This is the nature of 'safety' things, where things are double-checked, and any error throws a fault.

 

I'd argue that any error or event that warrants processor attention needs addressed regardless how many clock cycles are involved; that is the nature of safety, no?

 

Tedious as it may be, the architecture forces you to consider, and deal with, most every possible fault / failure.

 

I'd also consider the differences between ARMv4, which you seem to be familiar with, and ARMv7, which is what the R4F cores are more closely related to.

 

I am rather familar with ARMv7-AR (as opposed to ARMv6-M and ARMv7-M and ARM4vt [what a mess ;-)]). I would argue that the code you'd need to implement priority groups in software is rather identical for all non-M profiles.

 

Just looking at other Cortex-R4/R5/R7 implementations, like the Spansion FCR4, the all have interrupt controllers that have maskable priorities.

 

Again, I am just negatively surprised.

 

Here is what I usually do, where I'd need nice grouping. Say I have a bunch of I2C devices and some of them use time triggered reads, and some signal DRDY via a separate interrupt line to the MCU. If I put all of the interrupt sources for the I2C devices at the same priority level, then I can guarantee exclusive I2C access (say to my I2C transaction queue). If the interrupts are on different levels, I need to make sure thou other means that I2C transactions get queued properly, as a higher priority ISR could corrupt the transaction queue ... While it is not that outlandish tricky to get that done, the interrupt priority solution is easier and safer from a software point of view. 

 

- Thomas

[abecedarian 330]

Point made and understood.

[aseely 1]

Hi,

 

Full disclosure - I work on Hercules at TI and worked on the new launchpads - thrilled to see the first post not from a TI press release.
 

On VIM - you can actually map the interrupt requests to channels arbitrarily through the CHANMAP fields.  This is even avaiable through HalCoGen.

 

Doesn't give you automatic priority based masking of lower priority interrupts for nesting purposes, but it does let you group as you like and by doing this it should be easier to implement the nesting code as the bit masks can be straight-forward.     VIM is used instead of GIC because we try hard to keep compatibility all the way back to the TMS470 family which was introduced in the late 1990s although it was really not a catalog product.   

 

Would love to hear about why Energia would be good for these launchpads....  The libraries available for it are starting to make me think it could be interesting as they provide a lot more than GIO and ADC capability. 

 

The new launchpads introduce the XDS110 emulator.   There is actually a GDB Server available http://processors.wiki.ti.com/index.php/XDS_GDB_Agent .

And HalCoGen supports several toolchains, including GCC.    Not that I've had time to play with these myself but hope to get some time over the holiday.

 

Anyway - Thanks for noticing the new launchpads! 

 

Best Regards,

Anthony

[spirilis 1,265]

Hi,

 

Full disclosure - I work on Hercules at TI and worked on the new launchpads - thrilled to see the first post not from a TI press release.

 

On VIM - you can actually map the interrupt requests to channels arbitrarily through the CHANMAP fields.  This is even avaiable through HalCoGen.

 

Doesn't give you automatic priority based masking of lower priority interrupts for nesting purposes, but it does let you group as you like and by doing this it should be easier to implement the nesting code as the bit masks can be straight-forward.     VIM is used instead of GIC because we try hard to keep compatibility all the way back to the TMS470 family which was introduced in the late 1990s although it was really not a catalog product.   

 

Would love to hear about why Energia would be good for these launchpads....  The libraries available for it are starting to make me think it could be interesting as they provide a lot more than GIO and ADC capability. 

 

The new launchpads introduce the XDS110 emulator.   There is actually a GDB Server available http://processors.wiki.ti.com/index.php/XDS_GDB_Agent .

And HalCoGen supports several toolchains, including GCC.    Not that I've had time to play with these myself but hope to get some time over the holiday.

 

Anyway - Thanks for noticing the new launchpads! 

 

Best Regards,

Anthony

Anthony-

 

Thanks for chiming in!  I do think Energia would increase the utility of these chips if there were an open-source way to use them.  I briefly worked towards getting the 1st generation Hercules LaunchPads working with OpenOCD to do open source flashing of them ... and eventually (after wrapping my head around the whole process) ran into a brick wall in the form of the F021 Flash API.  I realized there would be no way to distribute an open-source solution for flashing to those chips.

 

So with that in mind, do you have any thoughts on this?  Do the new Hercules include a ROM bootloader that could be used instead, or would TI be willing to provide OpenOCD support (or some other software for flashing, ala "lm4flash" for Tiva, available on all Windows + Linux + OSX platforms) to allow the open-source Energia software to flash it?

Beyond that flashing piece, I can't think of any tangible reason why an Energia core couldn't be developed using ARM GCC to target this platform.  The newer Hercules chips do seem to pack a heck of a lot of horsepower compared to the other MCUs.

[aseely 1]

Hi Spirilis,

 

Thanks for the warm welcome!  

 

I think you're right - getting the F021 Libs open sourced would be difficult.   It's not so much the concern about the source as it is about what happens if parts are not programmed correctly - due to something going wrong in a rebuild.  The library keeps the variations a lot more under control.

 

I wonder exactly how the other MCU teams get around this, because F021 is used for the new Stellaris and C2000 devices.   Will have to poke at that.

 

In any case, if your entire toolchain were open-source, except you needed to download the F021 library from TI under it's click-wrap license and use the included library file in binary form for programming - would this be a show-stopper?   

 

The new XDS110 is supposed to support something called CMSIS-DAP that OpenOCD is also supposed to know how to use.  I have no idea of the details and wouldn't even know where to start.   

 

Best Regards,

Anthony

[spirilis 1,265]

Hi Spirilis,

 

Thanks for the warm welcome!  

 

I think you're right - getting the F021 Libs open sourced would be difficult.   It's not so much the concern about the source as it is about what happens if parts are not programmed correctly - due to something going wrong in a rebuild.  The library keeps the variations a lot more under control.

 

I wonder exactly how the other MCU teams get around this, because F021 is used for the new Stellaris and C2000 devices.   Will have to poke at that.

 

In any case, if your entire toolchain were open-source, except you needed to download the F021 library from TI under it's click-wrap license and use the included library file in binary form for programming - would this be a show-stopper?   

 

The new XDS110 is supposed to support something called CMSIS-DAP that OpenOCD is also supposed to know how to use.  I have no idea of the details and wouldn't even know where to start.   

 

Best Regards,

Anthony

I think a click-wrap method would be the only way.  I briefly considered it but decided the effort wasn't worth my time - didn't need all the power of the Hercules anyway (I tend to use msp430 more .... but the safety features and particularly ECC of the Hercules could be notable selling points even for simpler applications in the right scenarios).

 

The idea I had in mind was to write a simple HALCoGen+GCC stub that performed the F021 flash init procedure, then wrote a predetermined word of SRAM to a cookie value and halt.  Debugger code would poll that value to determine when the CPU was done initializing the flash.  Then it would proceed with its direct manipulation of the flash registers as usual.

 

By newer Stellaris, do you mean the TM4C129?  I know OpenOCD works fine with the ICDI and TM4C123 and I think 129 but I haven't tried flashing the 129.  Not sure how 'lm4flash' works either.  For C2000 in Energia, Trey has you do a click-wrap d/l and custom install of the C2000 compiler tools, but the serial uploader is his own program that talks to the C2000 serial bootloader, so that serial bootloader has all the intelligence for initializing the flash/etc built in, and embedded in the C2000's ROM.

 

My assumption will be that the XDS110 won't change anything here - XDS100 works fine with OpenOCD too, but it's only the transport mechanism; at the end of the day you still need to have a driver that understands how to manipulate the flash hardware on the MCU through register manipulation or some other technique (stub program in SRAM with an API, whatever).

 

Oh yeah, another bone I have to pick with the Hercules development cycle is HALCoGen's license.  The code generated by HALCoGen is covered under a highly restrictive license.  Yet HALCoGen is where all TI's intelligence for the peripherals is located, there's no open-source Driverlib like on Tiva/MSP430/CC3200 et al.  If that were to be a legal showstopper, then I think an Energia port would fall flat on its face unless TI devoted notable manpower from the Hercules team to do it (a cleanroom implementation of the Energia core that used no parts of HALCoGen) cause I'm sure not doing it :-)

[GrumpyOldPizza 15]

Hi,

 

Full disclosure - I work on Hercules at TI and worked on the new launchpads - thrilled to see the first post not from a TI press release.

 

On VIM - you can actually map the interrupt requests to channels arbitrarily through the CHANMAP fields.  This is even avaiable through HalCoGen.

 

Doesn't give you automatic priority based masking of lower priority interrupts for nesting purposes, but it does let you group as you like and by doing this it should be easier to implement the nesting code as the bit masks can be straight-forward.     VIM is used instead of GIC because we try hard to keep compatibility all the way back to the TMS470 family which was introduced in the late 1990s although it was really not a catalog product.   

 

 

Anthony, mind checking the TRM for me there ? I might have misunderstood them VIM documentation ... but the CHANCTRL[0:23] registers imply that you can map exactly one interrupt per channel. You cannot have multiple interrupt sources for one single channel. So you cannot really group, you just can establish an linear priority sequence.

 

- Thomas