[RnD_tek]

It’s not about matching the schematic, the Wizard allows you to change the pin that gets toggled.

It’s about the proper use of the Atmel Advanced Software Framework (ASF) for SAM Devices. This bug can be fixed by modifying the board support package LED_Blink_SAM sample. If you edit:

<user path>\AppData\Local\VisualGDB\EmbeddedBSPs\arm-eabi\com.sysprogs.arm.atmel.sam-cortex\Samples\LEDBlink_SAM\LEDBlink.c

And change every instance of:

PIO_P$$com.sysprogs.examples.ledblink.LEDPORT$$$$com.sysprogs.examples.ledblink.LEDBIT$$

to

PIO_P$$com.sysprogs.examples.ledblink.LEDPORT$$$$com.sysprogs.examples.ledblink.LEDBIT$$_IDX

The resulting binary will compile and run and actually blink the LED on the pin specified by the user in the Embedded Project Wizard.

The Atmel supplied ASF library for GPIO (pio.c and pio.h) has functions whose arguments identifying a specific pin want a pin index as defined by the library. The legal pin index numbers are found in the device specific header file (e.g. sam4e16e.h).

In the original post, the LED is connected to bit 22 on Port D. The Embedded project wizard translated that to PIO_PD22. While there is a definition in the device specific header for PIO_PD22 it is NOT the ASF index for that pin. In fact it is the same value as PIO_PA22 and PIO_PC22 so it is not a unique value, and not the value the ASF is expecting, but it will successfully compile with that value, it will not run.

So, if, in a subsequent release of VisualGDB’s Atmel ARM Cortex Devices board support package the sample LEDBlink.c file was changed, future customers will only have to worry about getting the correct pin and not then having to figure out why it still won’t blink the LED.

Attachments:

You must be logged in to view attached files.

[Author]

Posts