SAM4 LEDBlink sample has a bug

Sysprogs forums Forums VisualGDB SAM4 LEDBlink sample has a bug

This topic contains 2 replies, has 2 voices, and was last updated by  RnD_tek 4 days, 14 hours ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #32765

    RnD_tek
    Participant

    Received an Atmel (Microchip) SAM4E Xplained Pro board which has a SAM4E16E microcontroller. Created a new project with the Embedded Project Wizard. Chose defaults on the first page (Application, MSBuild, C, etc.). Chose the SAM4E16E on the second page. Chose the LEDBlink project on the 3rd page and set the LED Port Group to PORT D, LED Port Number to 22 and left the rest of the page alone. Chose the USB device CMSIS-DAP as discovered by VisualGDB, clicked “Test” and it succeeded.

    Then tried to Debug the project and the LED did not illuminate and after a few seconds, the micro reset and started over.

    The file “LEDBlink.c” that was generated by the wizard does not refer to the LED in the proper way for the Atmel¬†Advanced Software Framework. It refers to Port D 22 as PIO_PD22 when it should refer to is as PIO_PD22_IDX. If the 3 references to PIO_PD22 are changed to PIO_PD22_IDX, the example works:

    • This topic was modified 4 days, 17 hours ago by  support. Reason: formatting
    #32768

    support
    Keymaster

    Hi,

    This is by design. It is not viable for us to ship a separate LEDBlink sample for every possible board on the market. It is up to you to review the schematics of your board and select the values that would work.

    #32769

    RnD_tek
    Participant

    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.
Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.