I'm following the PWM lab guide and I'm able to blink the led via the debugger (Debug Configuration) .
Now I've set the Linker's Release configuration to "CMSIS\startup_gcc\production-smartfusion2-execute-in-place.ld" to see if it can blink from power-on without manually downloading the software via the debugger.
In Libero, I'm initializing the envm data storage to Release/Arrow_pwm_demo_eNVM.hex , generated the FPGA Array Data, Bitstream and programmed. However the led doesn't blink at power-on.
I also tried using the CMSIS\startup_gcc\debug-in-microsemi-smartfusion2-envm.ld link script, but that generates a Release hex file that does not import in Libero saying it's too big! Inspecting the hex file, it seems a problem with the very first line :0200000460009A
How do you generate a hex file such that it can be placed in the bitstream and the software runs at power-on?
Hi
this should actually not be very complicated, but it is also hard to tell what is wrong in your case. I did similar thing last with Engine-V project:
https://github.com/micro-FPGA/engine-V
there should be full project for creative board:
https://github.com/micro-FPGA/engine-V/tree/master/boards/microchip/CreativeBoard-SF2
(there is no full project for SMF2000 there)
I do not recall that I had any difficulties starting the ARM app from eNVM, it just worked...
In any case its nothing special related to SMF2000, you can use any docs and guides for SmartFusion2 in general. For the engine-V I used custom linker script, but you should be fine with the standard one.
Hope you get it up and running!
Thanks, I'll take a look!
BTW, I agree it's probably something simple I'm forgetting.. and probably not even related to the linker-script nor envm. Maybe the cpu is in reset.. or the generated bitstream is not the right file to program.. i.e. the stp file should be used?
Got it working..
1) SysTick_Handler seems to have issues with RELEASE configuration
2) NDEBUG needs to be defined in the RELEASE configuration
Regarding #2, without it, it hangs on the GPIO_config line:
HAL_ASSERT( HW_get_32bit_reg( cfg_reg_addr ) == config );
The strange part is that the settings it's trying to configure (GPIO_OUTPUT_MODE 5) is the same as what the Gpio core is set FIXED for (output). So in theory the configuration should read back "5" yet it reads "0"
It also works if I omit the config, and just rely on the Gpio Core's fixed output setting.
Anyone know how the GPIO core's configuration would not report as OUTPUT even though it's FIXED in the fabric, and is working (if un-initialized) as an output?