[Moved] C app on Cortex-M1 (Actel ProAsic3L)

[navry]

Hi,

I try to run my first simple C application in Cortex-M1 builded on ProAsic3L FPGA, but encountered some difficulties.
In this first project I want just to read 10 switches and turn on/off 10 LEDs. I created Cortex-M1 with peripherals from Actel IPcores. It has CortexM1 core, CoreAHBLite, CoreMemCtrl, CoreAHB2APB, CoreAhbSram, CoreAPB and CoreGPIO. In this case I think that memory map is important.

CoreAHBLite has:

Core	        Address	         Slot
CoreMemCtrl	0x00000000       0
CoreAhbSram	0x20000000	 2
CoreAHB2APB	0xA0000000       10

CoreAPB has:

Core	        Addreess	Slot
CoreGPIO	0xA0000000	0

I can synthesize it and load into FPGA. Then I use SoftConsole IDE to prepare application, it is simple, but I'm not sure if correct:

#include "hal.h"

#include "CortexM1_Top_hw_platform.h"

#include "core_gpio.h"

 

#define GPOUT_INIT_STATE        0x00000000

 

gpio_instance_t g_gpio;

 

int main()

{

 

    uint32_t io_state;

 

    /**************************************************************************

     * Initialize the CoreGPIO driver with the base address of the CoreGPIO

     * instance to use and the initial state of the outputs.

     *************************************************************************/

    GPIO_init( &g_gpio,    COREGPIO_BASE_ADDR, GPOUT_INIT_STATE );

 

    while( 1 )

    {

 

        /**********************************************************************

         * Read inputs.

         *********************************************************************/

        io_state = GPIO_get_input( &g_gpio );

 

        /**********************************************************************

         * Write state of inputs back to the outputs.

         *********************************************************************/

        GPIO_set_output( &g_gpio, io_state );

 

    }

}

I build it in Debug and tried to debug, but all what I see is the console output:

source .gdbinit

set arm fallback-mode thumb

target remote | "C:/Microsemi/Libero_v11.4/SoftConsole/Eclipse//../Sourcery-G++/bin/arm-none-eabi-sprite" flashpro:?cpu=Cortex-M1 "C:/Users/ds/Documents/FPGA/CortexM1_Test2/SoftConsole/CortexM1_Top_CortexM1Top_0/CortexM1_Top_CortexM1Top_0_app/Debug"

arm-none-eabi-sprite: Using memory map C:/Users/ds/Documents/FPGA/CortexM1_Test2/SoftConsole/CortexM1_Top_CortexM1Top_0/CortexM1_Top_CortexM1Top_0_app/Debug/memory-map.xml

arm-none-eabi-sprite: Target reset

0x00000000 in __text_start ()

set mem inaccessible-by-default off

load

Loading section .text, size 0x2f4 lma 0x0

Loading section .data, size 0x4 lma 0x2f4

Start address 0x64, load size 760

Transfer rate: 18 KB/sec, 380 bytes/write.

monitor debug-reset

thb main

Hardware assisted breakpoint 1 at 0x36: file ../main.c, line 18.

cont

 

Program received signal SIGTRAP, Trace/breakpoint trap.

0x00000000 in __text_start ()

Could you give me any hint what to do with it?

 

[std_match]

Re: C app on Cortex-M1 (Actel ProAsic3L)

I am not sure that this is your problem, but accesses to address zero in C is normally caused by a software bug. Because of this, it is normally forbidden, and the system environment tries to catch it as a help to the software developer.

My advice is to not use address zero, and treat all accesses to it as a crash.

 

[navry]

Re: C app on Cortex-M1 (Actel ProAsic3L)

I am not sure that this is your problem, but accesses to address zero in C is normally caused by a software bug. Because of this, it is normally forbidden, and the system environment tries to catch it as a help to the software developer.

My advice is to not use address zero, and treat all accesses to it as a crash.

I didn't know it. I will try to rebuild FPGA design to meet this advice. But in tutorials on Actel's website they use address zero: https://www.microsemi.com/document-portal/doc_download/130860-arm-cortex-m1-enabled-igloo-development-kit-user-s-guide (page 21).

 

[std_match]

Re: C app on Cortex-M1 (Actel ProAsic3L)

I can see that they map external FLASH or SRAM to address 0. That is OK, just avoid to use the first location.
Some systems store a zero value at address zero to minimize problems with unwanted zero pointer references (instead of catching the access and terminate the program).

 

[ace1903]

Probably debugger is instructed to catch unusual program behavoir. Look in settings for option to disable vector/signals catch in debug mode. Single stepping should be possible even with current setup. You can also enable option to verify downloaded image in RAM against program elf file. I havent Actel HW but I can verify program in cortex m simulator if you decide to share project files.

 

[navry]

Hi,

it looks like I don't know too much about this environment, I really appreciate your help. It will be much more pleasant, when I could at least run simple example.

I use CoreMemCtrl with address zero also for external memories (SRAM and Flash).

I attached software files. Unfortunatelly I can test it again in the next week on HW.

 

[ace1903]

Hi,

IDE created corrupted program image. isr_vectors section is missing at the begining of .text segment in final program image. There aren't initial values for program counter and stack pointer. You can try to initialize them mannualy with gdb set command. Or better, investigate why your program is corrupted (bit complicated if you are begginer in embedded sw development).

"I use CoreMemCtrl with address zero also for external memories (SRAM and Flash)." Why same address for SRAM and FLASH? Program is linked to execute in SRAM at address 0x0. FLASH is not needed in current setup. Check if hw is set up only SRAM to be mapped to address 0x0.