Forum : ARM
Original Post
Post Information | Post |
---|---|
February 8, 2012 - 6:46pm
|
I have a Reva kit with a STM32F107 daughter board. I would like to test some of the USB samples from ST, but these were done on a different eval board (STM3210C-EVAL). I did load the USB project (virtual serial port to be exact), but when I debug, the hardfault_handler is called. I suspect some clocking or memory access violation, which is where I am starting to dig, but wondered if anyone had already ported the code from the STM3210C-EVAL board over to the Reva kit? thanks Bill |
Hi Bill,
You should not have substantial differences concerning ST STM3210C-EVAL and the REva STM32F107-DB.
Here is a short list of the differences that impact the firmware:
- The GPIOs used are different (LEDs and buttons).
- No low-speed 32kHz crystal on the STM32F107-DB.
- The Ethernet Physical controller is a STE100P on STM32F107-DB, although it is a DP83848CW on the STM3210C-EVAL. This makes the Ethernet examples different on the two boards.
- The STM32F107-DB has a TS4657 audio codec, although the STM3210C-EVAL has a CS43L22.
Apart from that, you should not have much difference. The USB works the same.
So you must look somewhere else for your HardFault source.
Do standard examples (GPIO or the like) from the ST library examples work fine on your board? This is the first point to check (you may have some incorrect startup or library reference).
I hope this helps.
Best Regards,
Thanks Bruno,
I tried this with the STM3210C-EVAL board, but as you point out there is little difference when testing the USB. I still get the hardfault trap. I think this might be because the program size exceeds the 32K limit with my IDE. Is there a way to see the size of program and data? I checked the map file, but this does not list the absolute addresses of modules.
Thanks
Bill
Ok, a bit red-faced over here, but I solved the problem. I had changed the project properties to reflect the correct device I was using. Going though source, I noticed there were defines which were conditionally compiled depending on board type. I realized that I should have changed the configuration, not the target device. My bad, all working now!! Thanks for the help...
-Bill
Great job :cool: