ELECINF344/381

Interactive web site of Télécom ParisTech's ELECINF344/ELECINF381 Robotics and Embedded Systems classes (a.k.a. ROSE, 2012 session).

Categories

It’s rolling now!

We did it: we can activate the Tutobot motors now! After having brushing lots of bits to flash the FPGA image we could flash one that  that implemented the interface to the motors and LEDs with the MSS using the FPGA. You can checkout the first run in the attached video (don’t mind about the shake to the camera since I scared when the motors started :-D ).

It could had been earlier but we are still having issues to write the FPGA image file to the SPI memory. We already tried many approaches but we are still losing a few bits in every write (and when I mean a few, it is some 32 bits for the entire 191kbytes file). We still have to figure out how what is going on with the SPI interface.

Motor first run (ogg)
Motor first run (mp4)

Gabriel Teixeira

Tutobot’s FPGA flashed now.

The last days we had unpredicted issues with the system boot of the SmartFusion.

It looks like that the Actel’s SysbootInit is part of the reset system and we don’t have its the code. It must be configured by using the FlashPro provided by Actel, which is not compatible with the JTAG probe of Tutobot, and also FlashPro is not available for Linux.

Another issue with this is that it won’t run automatically a program that is stored in the eNVM of SmartFusion because it seems that the factory boot check the integrity of the sysboot and we couldn’t locate many documents explaining how this works.

We managed to flash the FPGA of the Tutobot after some “workarounds”. Let’s go by parts:

  1. We performed a minimal initialization of the SmartFusion to have a minimum set of peripherals working, like the GPIO. To test the GPIO, we wrote a simple program that blinks a LED. Since we didn’t attached a led directly to the MSS, we had to as to Alexis to attach a LED on the Zigbee sleep pin.
  2. The UART seems to be not configured in the FTDI. We could check that the Tutobot can write to both UART ports using the logic analyzer and the Zigbee can be configured and send messages, and also we could perform the same initialization using the eval board, but the FTDI chip won’t convert the RS232 signals to the USB, but we could already have a UART console through the Zigbee, which would be handy to work with the DirectC later.
  3. We also needed to use the SPI NVRAM to write the .dat image to flash to the SmartFusion FPGA. We were trying to work around this by trying to get a compressed .dat image from the MSS and decompress it directly to the FPGA, but this could be too slow and take some time to implement. Helen managed to bring SPI to life and we changed the existing SPI flash driver to the eval board to make it work with the SPI NVRAM (most commands were very similar, so this helped the development a lot).
  4. Since we already had SPI and UART working (albeit using the Zigbee), we could run DirectC to program the FPGA.

We now have the FPGA programmed, but we noticed the the Sysboot still is not being configured. We will to dump the Sysboot image from the eval board SmartFusion, as we noticed that the Sysboot code doesn’t change when we flash a new image to it (using FlashPro in Windows), just the configuration area.

Gabriel Teixeira

Flashing to the FPGA fabric with the Smartfusion

It was tricky but now we can do it. We have now a program that downloads an image to write on the FPGA fabric.

Initially the approach was to write using the UART to download the image but it seemed that this could take more time to develop than intended initially so the approach was changed to another were we compress the image and store in the MSS RAM.

One problem with this approach is that the compressed image might be bigger than the amount of memory that the MSS RAM can hold, so this may require segmentation of the FPGA image (it is still not yet verified if the image can be bigger than that). Another problem is that the binary that programs the image in the FPGA has to be relinked to the image, which needs to be loaded to the MSS again. This problem can be overcame by downloading the image to the MSS RAM, without relinking it to the application that flashes it to the SPI flash, then writing the image to the SPI flash memory.

Another problem to deal with is that this was tested only on the SmartFusion eval board, and the eval board uses a flash memory that is different from that of the Tutobot. Since that SPI flash has a compatible instruction set, we expect that it will work with having to fix it.

Gabriel Teixeira

New planning defined for Tutobot

Hello all,

Today we did a presentation to show the status of the project and to show how the last part of the project will be done. We defined a more detailed planning for the Tutobot since now we have the architecture of the PCB closed, so we can think about how to program everything. Our deadlines are long since we don’t know the arrival of the first unit. The following table show the attributed responsibilities and deadlines for each task:

Task Deadline Responsible
eNVM using OpenOCD 17/04 Helen
Libero project (IOMUX) 18/04 Thalita
FPGA fabric programming 18/04 Gabriel
FTDI configuration 23/04 Thalita
App libraries – Motor/Encoder 26/04 Gabriel
App libraries – FreeRTOS/Zigbee 26/04 Helen
App libraries – Sensors 26/04 Thalita
App libraries – LCD/Buzzer 29/04 Gabriel
App : Tutogrid 03/05 Helen
App : Tutobrush 03/05 Thalita

The two last tasks, Tutogrid and Tutobrush, are the development of two applications that will show some of the potential of the Tutobot.

Tutogrid is an application that discover the path from one predefined point to another over a grided floor filled with obstacles. The reactions are to be shown by the LCD and the buzzer. This app will show the usage of the line and collision sensors.

Tutobrush is an application that, using a pencil attached under the Tutobot, will draw over a paper a predefined picture and draw it in the LCD on the fly. The picture will be streamed by the Zigbee. This app shows the precision of the encoder

Gabriel Teixeira

DirectC compiled for SmartFusion

Hello all,

I spent the weekend until now to compile the DirectC for Smartfusion. In the beginning I thought I could compile it to be executed from the RAM, but the binary was too big for the RAM (the RAM can hold 64kb, but the binary was 76kb big). Thus I had to compile it for the Flash and relying that we will be able to flash it using openocd (and also that this will work). In parallel to this, the stdlib also had to be compiled with the DirectC, since it depends on many functions of the stdlib, like memset. In the beginning, the code was compiled with the option -nostdlib, which was fine while we didn’t have to use stdlib. Now we needed that, thus I removed the option, which would try to link crt0.o instead of the startup code provided by Actel (which we where using since the beginning). The solution was to add the -nostdlib option again and link explicitly the stdlib. Now it compiles ok.

Gabriel Teixeira

Makefile refactorization

Yesterday I finished the refactorization of the makefile that we use in our project. This will be useful to compile the projects without having to care which modules have to be linked. Initially, the drivers available are mostly low level like GPIO pins, I2C and UART interface, while the more high level ones (like Zigbee and the motors) will come after the board is received in order to be possible to test them before releasing.

Gabriel Teixeira

USB charger finished (hopefully)

Today Helen and me finished the schematics for the USB charger for the battery. We used the LTC4088 chip. This chip has a good current load capability and also can drive an external transistor to allow the power to be drawn directly from the battery. Hopefully this is the final design. We hope to do the routing over the weekend now.

Gabriel Teixeira

New USB charger schematics ready

Now I hope that this is done, for now. I chose the LTC4055 from Linear, which, besides having a Li-ion charger from USB power, it can also seamlessly switchover the source power from battery and the USB line, thus allowing the robot to be used also while recharging. The LTC4055 datasheet says that the output current is only 900µA, but, according to some feedback I got from asking to the professors and to stackexchange, I’m almost sure that this figure must be wrong (probably they meant 900mA). A design note from linear proposes a circuit that can balance the load from the USB power and the battery, which means that we can not only use the robot while it is recharging, but also to draw some power from the battery if the USB power is not enough to power the robot.

Gabriel Teixeira

USB charger plus power source done and undone

Most of the last week, including the weekend I spent searching for an architecture for the USB charger + a buck-boost converter for the board components, which would require a source for 3.3V and 5V, plus another separate regulator of 3V exclusively for the motor.

The USB charger schematics was mostly done by this Sunday (only the schematics of the CI was missing in the library, thus I left it to place in a second time) until we meet with the professor Monday. We found some downsides:

  • The battery would provide from 2.75V to 4.2V, thus the buck-boost CI that I chose could not provide the right regulation at 3.3V (since the CI could do buck or boost, but not both at same time).
  • There was an issue for using the robot while recharging.
  • The motor had to be changed to another one that needs 9V of input.
  • The components that required 5V were removed.
So all the time spent making the schematics was written-off. At least I could study how to build a (more or less) proper USB charger. Now I hope that the new power source architecture is ready and can be written on stone, or I risk to increase even more the time of the development.

Gabriel Teixeira

Articles about batteries

Today, me and Félix finished the article about batteries. The resulting article is published using Google Docs in this link for all the internet (potentially for our shame…) and is open for comments from everybody. Now I think that without any other tasks to do, I will be able to focus only on the project.

Gabriel Teixeira