Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
Group Actions
Engagement
  • Author Author: bprewit
  • Date Created: Date Created
  • Views 1282 views
  • Likes 0 likes
  • Comments 9 comments
Related
Recommended

Embedded Pi Part 1

bprewit

After anxiously awaiting arrival of the Embedded Pi board, I was (unfortunately) not able to take a look at it for quite some time. The description of the board piqued my interest -- I can see all sorts of possibilities for it.  My initial task was to use the examples provided to exercise the ePi and get a feel for the development flow required.

 

The Embedded Pi has three modes of operation:

     - The STM32 Standalone Mode, where the ePi is configured strictly as an STM32 board.  In this configuration, the STM32 is mapped to the pinout for Arduino shields.

     - The RasPi mode, where the ePi serves as a bridge between the RasPi and the Arduino shield;

     - The ST/Adapter Mode with the RasPi communicating to the STM32 via UART, and the STM32 is mapped to the Arduino shield.

 

I will be evaluating the ePi in all three modes, but first I need to set up the environment required to program it ..

 

Unboxing the Embedded Pi, the package contained

          - The Embedded Pi board

          - A USB Cable for linking it to a PC

          - A CDROM with the CooCox tools.

 

I opted to download the CooCox software from there website (here) using their CoCenter tool.  By using CoCenter, all that I had to do was click on "Install" and the product was downloaded and installed automatically.  Hard to beat that for easy installation.

 

However, there are a couple of "gotchas" in their software:  First, it's Windows-only.  This was somewhat disappointing as most of the larger semiconductor companies - TI, Microchip, and NXP to name a few -- are offering Linux and Mac versions of there development tools. Yes, there is plenty of literature available regarding developing for the STM32 on Linux or Mac -- but I have never been able to get anything to work correctly yet. The second issue, and it's a minor one, is that CoIDE requires a separate installation of GCC/Arm to function. Embest did provide an appropriate link, and I was able to get the CoIDE tool setup and configured fairly quickly.

 

The next hurdle was to actually get a program into the board.  I initially followed the directions here to program the ePi via the RasPi serial port. Note that the article says towards the end:

"If a prompt of “None” always appears, redo step 1 (press BOOT0 to reset the STM32)."; this is incorrect .. it should be "Hold BOOT0 while resetting the board" or words to that effect.

 

Unfortunately, no matter what I tried (different baud rates, attaching a ground, etc) I could not get the ePi to reliably program. In fact, the board had to be repeatedly reset to get it to program at all.Once I got frustrated with that approach, I re-read the User Guide, which very clearly states: "Since Embedded Pi has no debugger onboard, an external JTAG/SWD debugger is needed to

program Embedded Pi in the External Debugger Mode, like J-Link and CoLinkEx.".  It would have been nice to have included the SWD on-board (not uncommon) but Oh, well.

 

So, I ordered the CoLinkEx from Newark (here); the product arrived and functioned as designed and I was able to get a test program onto the board fairly quickly.

 

With that done, I was ready to try the CooCox examples; Part 2 will cover programming the ePi in STM32 Standalone Mode.

 

Note:  In the interest of completeness, I attempted to examine the CD-ROM that was included with the ePi; nothing I had (Windows, Linux, or Mac) would read it ... my conclusion is that the CD-ROM was defective.

  • in reply to shabaz

    I spent a bit of time looking at this over the weekend.  From STM Application Note 3155, the sequence is:

     

    1. Reset the board with BOOT0 held high (on the ePi, hold down the BOOT0 switch)
    2. Send an 0x7f to the UART.
    3. The expected reply is an ACK (0x79) on success or NACK (0xfe) on failure.

     

    So I hooked up my Bus Pirate and used it to send 0x7f following a reset  This worked maybe 50% of the time. Usually, if the NACK was received (autobaud failed) the board required an additional reset before the autobaud would work correctly.

     

    I hooked up an o'scope to measure the signal levels -- both signals were what I expected. (Note that both the Pi and the ePi are 3v3 logic), so I eliminated that as being the cause.

     

    Next, I used the stm32loader program to try to program the STM32 on the ePi.  This usually failed on the first attempt either without receiving a character or receiving a NACK.  The program as it is written displays "None" if no character is received or "NONE" if an unknown character is received.

     

    What I found out was that if I initially got one of the above responses, resetting the board with BOOT0 held down, sometimes a time or two, would usually allow the autobaud to succeed.

     

    So the problem seems to be with the STM32 itself, rather than the RPi or the loader program.

     

    Next step, when and if I have time, is to investigate the bootloader code ..

  • in reply to mconners

    Hi Mike,

     

    That's a nice trick, to use the SWD from the discovery board. I'm intending to use a FRDM board to program another Freescale processor in a similar vein. That route is nice since these boards are such low cost so they can be kept as general purpose programmers for those devices, but hopefully more and more microcontrollers will also have the capability to be programmed directly from USB too. Atmel has been really great in this respect for ages. Although not overly useful for development (it is too slow to use), at least it provides a way to get code fixes into a board quickly by anyone with a PC, with no knowledge needed other than how to install the USB driver and any software to connect to the bootloader. As far as I can tell, the Freescale devices can also do this, but it requires a specific bootloader to have been pre-installed by the user (I could be wrong). Still, this is progressive, and is streets ahead from how it used to be (e.g. the very expensive PIC programmers that were needed for the very inexpensive PIC chips).

  • in reply to bodgy

    I purchased the CoLinkEx from Newark Electronics here in the US; it's P/N 07W9770 from there.

  • in reply to shabaz

    I had the same issue as Bruce that is covered in another thread. I actually did write some python code that sent the 0x7f to the board, I don't remember what it returned, but it was not an ack. I can't remember if it returned 0 or nothing. Anyway, I had luck getting it to work via serial using a ftdi usb-> serial adapter, and also was able to use the swd connectors on an STM32VLDISCOVERY board, which are under $15 IIRC. So there is hope. But my honest opinion of the board was that it was too complex for beginners and advanced users could do the same thing with a Pi and something like a Freescale FRDM board for less money. A guy from Coo Cox is bugging me in the other thread to send him some photos of what's going on so I may revisit it this weekend.

     

    Mike

  • in reply to bprewit

    I've tracked down the order code for the Embest Colinkex Adapter Debug/JTag you reference for E-14 Australia - 2136554. It might also be the same for the UK, but haven't checked that site as yet.

     

     

    Colin