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 1464 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

    No question that the JTAG programmer solves the problem .. however, I can envision scenarios where a use might want to dynamically reprogram the ePi; this would require some means of transmitting a new program from the Pi to the ePi.

     

    Also, not everyone is going to have or be willing to pay for a JTAG programmer.  Programming from the Pi is a very desirable feature which everyone attempts first .. and I have noticed more than a few users who give up after not being able to get the serial download to work.

     

    Personally, I have an ARM RealView ULink2 that I would have liked to have been able to use to program the ePi but it's not supported in the CooCox tools and I didn't have the time to discovering how to make it work.  IMHO, having to buy a programmer for each board is emphatically senseless.

     

    Now, having said all that, if I have some time over the weekend I will try sending an 0x7f to the board and seeing what is returned.

  • in reply to bprewit

    Hi Bruce,

     

    It's hard to know what the problem could be. I looked at the STM doc here, it seems to state that the baud rate shouldn't matter (it will measure it when it receives the first character) and then it will send a single acknowledge character at the same speed. I suppose something like minicom could be run and the single character sent to see if the board at least responds back with the ack, but it is a special character (0x7f) that needs to be sent and I'm not sure how that is achieved with minicom (I use some freeware Windows program for the rare times I need to do that kind of thing). If there is an ack, then it would point to it being a problem with the RPI software, otherwise if there is no ack then there could be a problem putting the board into the bootloader mode.

    Still, if you have the JTAG then there is no need to do all this, it makes life simpler!

  • in reply to shabaz

    Actually, I tried adding a ground without success ..

  • Hi Bruce,

     

    It's a shame the website isn't clear on it, as you say, a ground connection is also needed (the CooCox website is assuming this, but doesn't specify it).

    But, it's probably a good thing you have the JTAG cable now if you are planning to use the particular chip, since usually (at least with other devices) serial port can be very slow to transfer programs, especially if you are debugging on the platform, and need to upload code frequently.