Supporting STM32F429i-Discovery

[TibaChang]

Supporting STM32F429i-Discovery

• The devices doesn't support auto baudrate.
  • The baudrate is tested at 115200,and works well!
  • It is set to be the default,too.
• Supports for using USART1~3
  • The default is to use USART1.
  • USART1~3 can be used on many combinations(pins).
  • However,it is configured to be using the pins as the follows:
  • USART1:(Tx,Rx)=(PA9,PA10)
  • USART2:(Tx,Rx)=(PD5,PD6)
  • USART3:(Tx,Rx)=(PB10,PB11)
• GDB command on the host
  • arm-none-eabi-gdb ./HelloWorld.elf --baud 115200 -ex "set target-charset ASCII" -ex "set print pretty on" -ex "set remotelogfile mri.log" -ex "target remote /dev/ttyUSB0"
  • The host runs on Ubuntu15.04 64-bits(Intel I7).

[adamgreen]

Cool!

I have a few comments based on my initial scan through the new sources:

• I don't have one of these boards so I can't test it in the future. I can just make sure that any updates I or others make don't break the build.
• Your changes are so isolated to your new device that they have little chance of causing issues for the existing / tested platforms. This is excellent!
• Do you really need devices/stm32f429xx/stm32f429xx.tar in this pull request?
• Add your copyright to my files that you copied and modified to support the new platform. Examples include:
  • boards/stm32f429-disco/stm32f429-disco.c
  • devices/stm32f429xx/stm32f429xx_asm.S
  • devices/stm32f429xx/stm32f429xx_init.c
  • devices/stm32f429xx/stm32f429xx_init.h
  • devices/stm32f429xx/stm32f429xx_usart.c
  • devices/stm32f429xx/stm32f429xx_usart.h
• Some of those same board/device sources are now using a coding style that is inconsistent with existing MRI device/board sources. You are using K&R and the rest use C++ where the opening brace should be on its own line.
• Remove install rule from makefile in this pull request. It is Posix only and specific to your environment. It makes sense to keep it in your local fork but not in this, the main one.

[TibaChang]

Thank you for your comment!

• The devices/stm32f429xx/stm32f429xx.tar is added by my mistake,and it is removed.
• Fix the inconsistent coding style!
• Remove the "install" rule.
• Add my copyrights to the files,listed in your comment.
  • However,this is my first time to use the copyrights(and also a beginner in github), I am not sure whether I use them in the right way.Thank you for your advices!

[adamgreen]

The copyright comment updates and other changes look good! I have added a few comments above. Once those are addressed, I will merge. I only noted one place where you used tabs instead of expanding to spaces but there are others that you should find and change as well.

Thanks again!

[TibaChang]

(Sorry,I couldn't find your public email,so I use the reply.) (My email address:jaredcjr.tw@gmail.com) Hello,Adam I am Jared(JaredCJR), a university student in Taiwan,interested in your project including CrashDebug,CrashCatcher and mri. Therefore,I try to let the CrashCatcher works on the STM32F429i-Discovery.It seems to be works properly(?). However, I have some question about the CrashDebug.I list them as below,hoping that it will dismiss my confuse and will not take you too much time!

• What command and dumpfile could I use for CrashDebug to run with the CrashCatcher? I have seen the guide over here https://github.com/adamgreen/CrashDebug#how-to-run,but I still being confused.

Due to I don't know what should I implement for the "dumpfile". I use the follow command to run the mri successfully.

(Please ignore the path) arm-none-eabi-gdb ./CrashingApp_StdIO.elf --baud 115200 -ex "set target-charset ASCII" -ex "set print pretty on" -ex "set remotelogfile mri.log" -ex "target remote /dev/ttyUSB0"

And I think the following command might be work.But it seems to failed,if the CrashDump.txt doesn't exists.

(Please ignore the path) arm-none-eabi-gdb ./CrashingApp_StdIO.elf --baud 115200 -ex "set target-charset ASCII" -ex "set print pretty on" -ex "set remotelogfile mri.log" -ex "target remote | /CrashDebug/CrashDebug --elf ./CrashingApp_StdIO.elf --dump CrashDump.txt"

and it enter the gdb seems to be good when the "CrashDump.txt" exists. However,I am not sure what should be the "contains the contents of RAM and the CPU registers." https://github.com/adamgreen/CrashDebug#crashdebug-parameters

Could you able to provide me some example about the "dumpfile"?

• How could I get into main without gdb?

In the sample,I could see the prompt for user input when I connect with gdb,but I just seen garbled without gdb.I have already tested the StdIO sample in gcc4mbed doesn't work for STM32F429. Is the problem happened due to this problem? Meaning that I need to use my own implementation to communicate with the application. I connect between mri and gdb using USART1,and USART3 for the CrashCatcher.

• What is the rule of the CrashDebug?

CrashCatcher are able to output the dump information during hardfault. And,MRI are used to communicate with gdb. I am wondering what could CrashDebug do ?

Thank you very much! Also for the advices in the pull request. I will fix them maybe next week,maybe try to find someone to help me let the code be better them now!

Best wishes,JaredCJR

2015-11-26 5:43 GMT+08:00 Adam Green notifications@github.com:

The copyright comment updates and other changes look good! I have added a few comments above. Once those are addressed, I will merge. I only noted one place where you used tabs instead of expanding to spaces but there are others that you should find and change as well.

Thanks again!

— Reply to this email directly or view it on GitHub https://github.com/adamgreen/mri/pull/3#issuecomment-159737766.

[adamgreen]

I look forward to your PR updates.

I have responded to your CrashCatcher/CrashDebug questions in a separate e-mail.

[TibaChang]

Your advices really let me learn a lot! Thank you for your reply!!!

[adamgreen]

I have made a few more code style changes and pushed them up into my https://github.com/adamgreen/mri/tree/JaredCJR-master branch. The specific commit is 5406bfe270e5df16a2b0fec05a6198fe978b74ed

Please review and if you like it then I will merge it all into master.

Thanks again!

[TibaChang]

I think the change is great! Thank you for your efforts,I learn a lot again!

[adamgreen]

I have merged into my master branch a snapshot of your branch from early yesterday. I will close this PR since that accepts the bulk of your changes. It appears that you amended one of the most recent commits after I pulled and added in my changes and those haven't been merged into master. Please re-submit whatever those changes were in a new PR after merging/rebasing my latest master branch. I know that a recent comment you added to makefile is missing from what I just merged into master.

[adamgreen]

I have also added a Devices Supported list and included this STM device in the list.

Thanks again!