search

labapart / polymcu

An open framework for micro-controller software
http://labapart.com/products/polymcu
202 stars 41 forks source link

Support for STM32 F767ZI #4

Closed sergiuszm closed 3 years ago

sergiuszm commented 7 years ago

Have you tried to investigate the issue with the embedded HW debugger? Are you sure the code is running well? Can you see the LED turns on with the application Examples/Barematal? If you cannot then it means the issue is before.

I don't have a HW debugger, unfortunately. I can get LED2 on, but nothing more. I have even tried to turn on/off LED2 within a few iterations but without success.

On board without HW debugger, I actually make sure the LED works fine and I try to investigate how far the code is running.

So, LED works, but nothing more. I can turn on and off three LEDs available on board but if I use "puts" or "printf" function then nothing more works.

I have squashed all commits into, reverted changes to /CMakeLists.txt and done other suggestions.

oliviermartin commented 7 years ago

Are you saying the LEDs cannot be turned on after calling puts() or printf()? In general it is better to use puts instead of printf at the early stage of board bring-up as puts use much less stack than printf and sometimes stack overflow is an issue.

The next step would be to add set_led() into Device/ST/Driver/VCom/driver_USART.c to see if the functions ARM_USART_Send() are called properly. Maybe ensure hardware_init_hook() is also called - again with set_led().

sergiuszm commented 7 years ago

So, I have checked that all steps from hardware_init_hook() are called with success, and the function itself is called.

The problem is with ARM_USART_Send() which is not called at all. I can't get any LED turned on with this function.

Do you have any ideas how can I check why this function is not called?

oliviermartin commented 7 years ago

We are getting closer!

It's _write() which call Driver_UART_DEBUG.Send() (see: Lib/PolyMCU/uart_device.c). Ensure the function _write is called...

Can you send me your ELF file. It should be in Build/Application/Examples/Baremetal/Baremetal_example.elf

sergiuszm commented 7 years ago

Thanks for help!

I found out that Driver_UART_DEBUG.Send() is called by _write() but I am still looking for a code flow. Especially where _write() is called and when - so, I am still fighting.

In meantime, this is my Baremetal_Example.elf: link

oliviermartin commented 7 years ago

Are you building Baremetal_Example.elf in Debug or Release build? I was trying to disassemble it to check the code flow but I could not get the symbols. Which toolchain are you using?

sergiuszm commented 7 years ago

My mistake. Now I have built Baremetal_Example with Debug flag: link

I am using arm-none-eabi-gcc v 5.4.1

This is the full output of building process:

 cmake --verbose -DCMAKE_BUILD_TYPE=Debug -DAPPLICATION=Examples/Baremetal -DBOARD=ST/STM32F7xx_Nucleo ../ && make
-- The C compiler identification is AppleClang 8.0.0.8000038
-- The CXX compiler identification is AppleClang 8.0.0.8000038
-- Check for working C compiler: /usr/bin/cc
-- Check for working C compiler: /usr/bin/cc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++
-- Check for working CXX compiler: /usr/bin/c++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- The ASM compiler identification is Clang
-- Found assembler: /usr/bin/cc
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/serchio/Documents/Projects/sergiuszm-polymcu/build
Scanning dependencies of target polymcu
[  6%] Building C object Lib/PolyMCU/CMakeFiles/polymcu.dir/misc.c.o
[ 13%] Building C object Lib/PolyMCU/CMakeFiles/polymcu.dir/mailbox.c.o
[ 20%] Building C object Lib/PolyMCU/CMakeFiles/polymcu.dir/uart_device.c.o
Linking C static library libpolymcu.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libpolymcu.a the table of contents is empty (no object file members in the library define global symbols)
[ 20%] Built target polymcu
Scanning dependencies of target device_st
[ 26%] Building ASM object Device/ST/CMakeFiles/device_st.dir/STM32F7xx/Source/gcc/startup_stm32f767xx.s.o
[ 33%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx/Source/system_stm32f7xx.c.o
[ 40%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal.c.o
[ 46%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_cortex.c.o
[ 53%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_gpio.c.o
[ 60%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_pwr_ex.c.o
[ 66%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_rcc.c.o
[ 73%] Building C object Device/ST/CMakeFiles/device_st.dir/STM32F7xx_HAL_Driver/Src/stm32f7xx_hal_uart.c.o
[ 80%] Building C object Device/ST/CMakeFiles/device_st.dir/Driver/VCom/Driver_USART.c.o
Linking C static library libdevice_st.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libdevice_st.a the table of contents is empty (no object file members in the library define global symbols)
[ 80%] Built target device_st
Scanning dependencies of target board_st
[ 86%] Building C object Board/ST/CMakeFiles/board_st.dir/STM32F7xx_Nucleo/board.c.o
[ 93%] Building C object Board/ST/CMakeFiles/board_st.dir/STM32F7xx_Nucleo/stm32f7xx_nucleo.c.o
Linking C static library libboard_st.a
warning: /Library/Developer/CommandLineTools/usr/bin/ranlib: warning for library: libboard_st.a the table of contents is empty (no object file members in the library define global symbols)
[ 93%] Built target board_st
Scanning dependencies of target Firmware
[100%] Building C object Application/Examples/Baremetal/CMakeFiles/Firmware.dir/main.c.o
Linking C executable Baremetal_Example.elf
/usr/local/Cellar/arm-gcc-bin/5-2016-q2-update/bin/../lib/gcc/arm-none-eabi/5.4.1/../../../../arm-none-eabi/bin/ld: warning: cannot find entry symbol arch_paths_first; defaulting to 00000000080001f8
   text    data     bss     dec     hex filename
  14528     124    1700   16352    3fe0 /Users/serchio/Documents/Projects/sergiuszm-polymcu/build/Application/Examples/Baremetal/Baremetal_Example.elf
[100%] Built target Firmware
oliviermartin commented 7 years ago

I do not know if I have done anything wrong but I can get the list of symbols from the ELF. Both ELF files you gave have the same size.

Maybe send me the disassembly to make it faster. To disassemble your ELF file: arm-none-eabi-objdump -S Baremetal_Example.elf

sergiuszm commented 7 years ago

Sure, here is the link to the disassembled file: link

oliviermartin commented 7 years ago

Hmm, I had the same output. If it was a debug build I would expect to see symbols and C code as part of the disassembly. Could you run this command in your build directory: grep BUILD CMakeCache.txt We should expect to see: CMAKE_BUILD_TYPE:STRING=Debug

sergiuszm commented 7 years ago

Yes, I got CMAKE_BUILD_TYPE:STRING=Debug from CMakeCache.txt.

oliviermartin commented 7 years ago

I am not sure why the disassembly code is not how it should be. Anyway, let's try something else for now. Could you hack this line in CMakeLists.txt#L347

add_definitions(-D__CORTEX_M7)

And replace it by:

add_definitions(-D__CORTEX_M7 -D__FPU_PRESENT -D__FPU_USED)

And try again...

sergiuszm commented 7 years ago

I have tried, but the result is the same (I think).

I have uploaded bin file to nucleo board and result is the same.

Here's the disassembled file: link

oliviermartin commented 7 years ago

Can you send me the exact command line you are typing (and ideally the same source code your are using). I will build it myself and see if there is an issue with the compilation flags. The disassembly is not what I would expect to see.

sergiuszm commented 7 years ago

This is the command that I use: `cmake --verbose -DCMAKE_BUILD_TYPE=Debug -DAPPLICATION=Examples/Baremetal -DBOARD=ST/STM32F7xx_Nucleo ../ && make``

This is a patch file that reflects all changes I have made: patch

oliviermartin commented 7 years ago

Are you building Baremetal_Example.elf in Debug or Release build? I was trying to disassemble it to check the code flow but I could not get the symbols. Which toolchain are you using?

On 27 October 2016 at 14:08, Lukasz Sergiusz Michalik < notifications@github.com> wrote:

Thanks for help!

I found out that Driver_UART_DEBUG.Send() is called by _write() but I am still looking for a code flow. Especially where _write() is called and when - so, I am still fighting.

In meantime, this is my Baremetal_Example.elf: http://dsh.re/60dde http://url

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/labapart/polymcu/pull/4#issuecomment-256635637, or mute the thread https://github.com/notifications/unsubscribe-auth/AFfaQ86x07hQ2PAU4qViQ8XIx0_9MxFFks5q4KJTgaJpZM4KhxNd .

sergiuszm commented 7 years ago

Looks like your comment is a repeat of previous comments. Was it wrongly send? I don't know if you wanted to add something else :)

oliviermartin commented 7 years ago

Sorry, I tried to reply directly from the email and not from the github interface. I noticed there was a lag (the message did not appear in the github discussion). So I am guessing it is the email I sent 2 hours ago.

I will try to build the code later (probably tonight) and see if I can notice something.

oliviermartin commented 7 years ago

My hack was not fully correct, it should have been:

add_definitions(-D__CORTEX_M7 -D__FPU_PRESENT -D__VFP_FP__)

I do not have arm-none-eabi-gcc v 5.4.1 but arm-none-eabi-gcc v 5.3 on my computer.

I have not seen anything suspicious in my disassembly file. printf() and puts() both uses the heap. You could try to use write() instead to check if it is a heap issue. For instance:

const char* str = "Hello\n";
write(1, str, strlen(Hello) + 1);

The fact you cannot produce a clear disassembly file worry me a bit. Maybe your Build directory is dirty and you should do rm -Rf * before building.

I have attached my built files Baremetal_Example.bin, Baremetal_Example.elf, Baremetal.disasm using your patch: Nucleo.zip. I do not have the board to test it.

sergiuszm commented 7 years ago

I have flashed your build to the device but the problem still remains.

const char* str = "Hello\n"; write(1, str, strlen(str) + 1);

I got a strange serial output - but just once (I run this code in the endless loop): $$$081802210D2F651E326BFC3B

I think the problem with a disassembly in my case is a MacOS which might be missing proper debug flags in kernel config. I will try with a linux virtual machine tomorrow to confirm this case.

oliviermartin commented 7 years ago

Ensure you do not have Hardware control flow on your serial terminal. Baud Rate should be 115200, Data Bits: 8, Stop Bit: 1, Parity: None, Flow Control: None

The debug flag are nothing to do with the kernel config but with the cross-compilation toolchain.

sergiuszm commented 7 years ago

I am using screen to get serial data. It works well with STM32 L467RG so I assume that it should be the same with F767ZI.

Now I am preparing linux. I will let you know if I have found something.

You are right with the debug flag - I was thinking about something else, sorry.

sergiuszm commented 7 years ago

By the way - are you eager to communicate in more flexible way? It takes some time to reply here.

sergiuszm commented 7 years ago

I have compared a disassembled files for F7xx and L4xx but I didn't find anything interesting. Maybe I just don't know what I am looking for.

I have verified if everything is fine with my F767ZI board through mbed online compiler and I got a correct serial output from there.

Do you have any other ideas what I should be looking for?

sergiuszm commented 3 years ago

It is a really old discontinued PR.