Atmel ARM Cortex (or NXP? or STM32?)

[mikerj]

The device I lost a considerable amount of hair over was the STM32F103RE.  It appeared to be designed around a collection of poorly documented race conditions enclosed in a box marked "I2C".  It was slave operation that caused the most issues.

I used a sibling device, the STM32F101. IIRC you had to follow different steps if you wanted to receive 1, 2 or three or more bytes. Since we could design the protocol in our application as we saw fit, we ensured we always transferred at least three bytes, which was the simplest case. The recommendation was also to use DMA or to reserve the highest priority interrupt for I2C and never disable it. Most of this nonsense seems to be gone in the "new" I2C peripheral.

It's much more reliable with DMA, but since we are a slave to other vendors equipment we have no idea of the incoming frame length so had to go for an interrupt driven scheme.  We also don't know the exact bit rate or I2C timings being used, other than they should be compliant to I2C fast mode standards (400kHz max).  Previously we have seen reliable operation at e.g. 100kHz only for it to fail at, say 88 kHz.

It's been working reliably for a couple of years now, but it's part of the code that we have to tread very carefully around if we ever need to make changes, and spend a lot of time doing extended regression using I2C bit rates and timings that have caused trouble previously.

Yeah even st acknowledges the crappy i2c peripheral BUT has written a solution.
It is called something like I2CPAL and can be downloaded from their site, it is the only way of getting it to work properly.

I have hunted around for this but been unable to find it. Is it simply some updated I2C example code, or something more complex such as a code generator? I don't suppose you have a link?

[dannyf]

Even that implementation is not universal: it does not work for all stm32f families.

[paulie]

STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.

To check boot0 pin I've sent 0x7f with hyperterm and got response but beyond that??? Can you elaborate on how to flash a file?

[mikerj]

STM32's for example. All you need is a serial program (HyperTerminal for example) and you are done.

To check boot0 pin I've sent 0x7f with hyperterm and got response but beyond that??? Can you elaborate on how to flash a file?

HyperTerm is far from ideal for this as you need to send non-printing characters to request various operations.  Its much easier to use the ST Flash Loader Demonstration or one of the open source utilities.

[Kjelt]

I have hunted around for this but been unable to find it. Is it simply some updated I2C example code, or something more complex such as a code generator? I don't suppose you have a link?

Sorry for the delay, was in Italy on holiday and the internet there was almost non-existing, I felt thrown back 15 years in time 
Anyway, just looked it up for you, it is called CPAL and you can find/download it on the http://www.st.com website , select STM32 32-bit ARM Cortex MCUs, select software, select STM32 Embedded Software Examples : 90
and on that page search and find  (CPAL) or (UM1029)  see pic below.

[sporadic]

The Atmel IDE is currently unbeatable, as long as you are a Windows user. The combination of good datasheets and Atmel Studio make them hard to beat, even if the silicon doesn't have quite as many features as some of the competitors.

Oh, and their debuggers (JTAGICE3) are cheap and really good.

The newer Atmel ICE Basic comes in even cheaper at $50.

[jakeypoo]

Toolchain was a big challenge for me. Development files (linker scripts and startup files etc.) are included for two different GCC-based commercial products, as well as a proprietary one, but it still took me some steep learning curve to get it running. Now every time I go to work with these I have to wonder if my toolchain still works or if I'll have to go through that again... I think this is pretty much the case with any of them though if you're not going to use the provided tooling directly.

Toolchain has been a pita for me as well. Trying to get a LPC11U35 running using arm gcc baremetal compiler and little else. Looking at people's linker script examples, startup_xxx.c files, makefiles, CMIS has been confusing to say the least. I suppose you could just use one of the many easy-to-use toolchains, but I don't like paying for those kind of tools and I don't like to get locked into a toolchain.

Someone needs to write a tutorial for migrating from avr-gcc to arm-none-eabi-gcc. I mean, cortex M0[ or M3,M4] is supposed to be a replacement for 8-bit micros, right? If you look at the "Migrating from PIC..." document on the arm website, there's not much useful info there.

[andyturk]

Someone needs to write a tutorial for migrating from avr-gcc to arm-none-eabi-gcc. I mean, cortex M0[ or M3,M4] is supposed to be a replacement for 8-bit micros, right? If you look at the "Migrating from PIC..." document on the arm website, there's not much useful info there.

It's actually not that hard. Start another thread though...

[paulie]

HyperTerm is far from ideal for this as you need to send non-printing characters to request various operations.  Its much easier to use the ST Flash Loader Demonstration or one of the open source utilities.

far from ideal? true. but its quite easy to send non-ascii using alt-keypad or send text option. i was just interested in whether dannyf had a point or just blowing smoke.

[gmb42]

I found this some time ago which is a reasonable intro to the STM32: Discovering the STM32 Microcontroller

[dannyf]

Toolchain has been a pita for me as well.

CoIDE provides full support for those chips. Most of the chips you will have native support - you get to pick the chip and CoIDE will set up the project for you.

For those chips without native support (like some LPC chips), you can build your project as a regular CMx core, and manually copy in the respective start-up file and library files. Setting up such a project is fairly simple, once you know your way around. No need to play with linker script.

Debugging is supported also: for LPC, CoIDE provides support for CoLink, J-link, or older ftdi-based debuggers.

[CC58]

NXP toolchain LPCexpresso has been very easy to use.  The IDE and C compiler are integrated and free.  It uses a cheap $50 JTAG debugger so you don't have to shell out $$$$ to buy a generic one.  Lots of free code on their site too.

[dannyf]

LPC11U35

The whole LPC11xx families are interesting and weird in how they arranged the port registers. On most other chips, the registers associated with a port, like output data registers, input data registers, direction registers, set registers, clear registers, and toggle registers, etc. are grouped together by port. So you can have a struct pointed to the base address of a port and everything falls into place. All other LPC chips fall to that category, other than the LPC11xx family.

For the LPC11xx family, they grouped those registers by functionality. So Port0's output data register is next to Port1's output data register, Port1's set register is next to Port2's set registers, etc. Making the programmer's life unnecessarily difficult.

[ve7xen]

CoIDE provides full support for those chips. Most of the chips you will have native support - you get to pick the chip and CoIDE will set up the project for you.

CoIDE is Windows only. If I wanted to use Windows, I would just use one of the size-limited "free" toolchains with official support.

[jakeypoo]

Toolchain discussion is starting to hijack this thread. I'll start a new one.

[nctnico]

LPC11U35

For the LPC11xx family, they grouped those registers by functionality. So Port0's output data register is next to Port1's output data register, Port1's set register is next to Port2's set registers, etc. Making the programmer's life unnecessarily difficult.

Why would that be difficult? I just write P0DATA |= (1<<1) to set bit 1 (where P0DATA is a macro with a volatile pointer to Port 0's data port address). Using structs doesn't add much clarity for trivial things like GPIO ports.

[mrflibble]

Toolchain discussion is starting to hijack this thread. I'll start a new one.

Link to other discussion.

[mikerj]

I have hunted around for this but been unable to find it. Is it simply some updated I2C example code, or something more complex such as a code generator? I don't suppose you have a link?

Sorry for the delay, was in Italy on holiday and the internet there was almost non-existing, I felt thrown back 15 years in time 
Anyway, just looked it up for you, it is called CPAL and you can find/download it on the http://www.st.com website , select STM32 32-bit ARM Cortex MCUs, select software, select STM32 Embedded Software Examples : 90
and on that page search and find  (CPAL) or (UM1029)  see pic below.

Thanks, just looking through this now