This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

ARM GCC compiles but bin file is very small and download but does not work

I am using the sdk version 11 and arm-none-eabi-gcc version 5.4 on linux mint to compile the blinky test application. I have pointed the Makefile-posix at the location of the compiler gone into the folder for the pca10028 board and into the s130 folder. When i run make everything appears to compile and link with no errors and a bin and a hex file is produced. However the hex file produced is much smaller than the example hex file in the hex folder(which works fine). When i download this hex file it does not do anything at all. The elf file produced is around 340k while the bin file is about 1k and hex is about 3k. I have used keil to compile and got a working hex file but I need to get GCC working. I have not modified the make file so any ideas what might cause this kind of symptom. I have tried using a slightly old version 4.9 of the arm gcc as well but same results

Parents
  • Hi Richard, a 1k binary for a program that just blinks a LED sounds resonable to me.

    You can have a look into the map file and see if at least some function you expect to be in the outout are there (main, reset vector etc.). Or you can produce an annotated list file "arm-none-eabi-objdump -S blinky.elf" and see if the resulting assembler code makes sense to you.

    The start of the binary should contain the address of the initial stackpointer followed by the address of the Reset_Handler() function.

    You can use a debugger and set a break point at Reset_Handler() and debug the setup procedure.

    cheers, Torsten

Reply
  • Hi Richard, a 1k binary for a program that just blinks a LED sounds resonable to me.

    You can have a look into the map file and see if at least some function you expect to be in the outout are there (main, reset vector etc.). Or you can produce an annotated list file "arm-none-eabi-objdump -S blinky.elf" and see if the resulting assembler code makes sense to you.

    The start of the binary should contain the address of the initial stackpointer followed by the address of the Reset_Handler() function.

    You can use a debugger and set a break point at Reset_Handler() and debug the setup procedure.

    cheers, Torsten

Children
No Data
Related