sparkfun / ambiqsuitesdk Goto Github PK

As evidenced by changes required for this PR in the mbed port it is difficult to fully disable the FIFO on UART while using HAL configuration.

branch 2.4.2-patch-uart-fifo-config adds an additional configuration function which allows the FIFO to be enabled (as usual) or disabled (addtl. feature)

misleading documentation issue with am_hal_wdt

looking at the current version of this which I believe uses sdk 2.2

if you look in am_hal_wdt.h then you can see that ui16ResetCount is a 16 bit counter. where the datasheet for the apollo3 it clearly states that it's an 8 bit counter.

if I set up the wdt for 7200(2 hr) seconds with the 1hz counter, I would expect it not to reset if i feed it every hour. What actually happens is that it resets every 32 seconds. that's because 7200 mod 256 is 32.. so the msb's are thrown away..

so if you use this, I think the longest wdt you can make is 16*255=4080 seconds- a bit over an hour.

make works but make bootload ... does not...

Makefile:149: *** Error: BOARDPATH must be provided. Stop.

Followed Getting Started. : Details:....

$ YOUR_BOARD=redboard_artemis_nano

kerry@Kerry-pc MINGW64 ~/Documents/AmbiqSuiteSDK/boards_sfe/common/examples/blinky/gcc ((9c31f07...))
$ make BOARD=$YOUR_BOARD
Makefile:112: Using BOARD=redboard_artemis_nano at ../../../../redboard_artemis_nano
Makefile:117: warning: you have not defined COM_PORT. Assuming it is COM4
Makefile:121: warning: you have not defined PYTHON3. assuming it is accessible by 'python3'
Makefile:125: defaulting to 115200 baud for ASB
Makefile:129: defaulting to 921600 baud for SVL
Makefile:134: warning: you have not defined SDKPATH so will continue assuming that the SDK root is at ../../../../..
Makefile:142: warning: you have not defined COMMONPATH so will continue assuming that the COMMON root is at ../../../../common
Makefile:163: warning: you have not defined PROJECTPATH so will continue assuming that the PROJECT root is at ../../../../common/examples/blinky
Makefile:170: CONFIG=../../../../common/examples/blinky/gcc/redboard_artemis_nano/bin
Compiling gcc ../../../../common/examples/blinky/main.c
Compiling gcc ../../../../common/tools_sfe/templates/startup_gcc.c
Compiling gcc ../../../../../utils/am_util_delay.c
Compiling gcc ../../../../../utils/am_util_faultisr.c
Compiling gcc ../../../../../utils/am_util_stdio.c
Compiling gcc ../../../../../devices/am_devices_led.c
Linking gcc ../../../../common/examples/blinky/gcc/redboard_artemis_nano/bin/blinky_asb.axf with script ../../../../common/tools_sfe/templates/asb_linker.ld
Copying gcc ../../../../common/examples/blinky/gcc/redboard_artemis_nano/bin/blinky_asb.bin...

kerry@Kerry-pc MINGW64 ~/Documents/AmbiqSuiteSDK/boards_sfe/common/examples/blinky/gcc ((9c31f07...))
$ make $YOUR_BOARD bootload_asb
Makefile:109: warning: no BOARD specified, will fall back to BOARDPATH for arbitrary bsp locations
Makefile:117: warning: you have not defined COM_PORT. Assuming it is COM4
Makefile:121: warning: you have not defined PYTHON3. assuming it is accessible by 'python3'
Makefile:125: defaulting to 115200 baud for ASB
Makefile:129: defaulting to 921600 baud for SVL
Makefile:134: warning: you have not defined SDKPATH so will continue assuming that the SDK root is at ../../../../..
Makefile:142: warning: you have not defined COMMONPATH so will continue assuming that the COMMON root is at ../../../../common
Makefile:149: *** Error: BOARDPATH must be provided. Stop.

kerry@Kerry-pc MINGW64 ~/Documents/AmbiqSuiteSDK/boards_sfe/common/examples/blinky/gcc ((9c31f07...))
$ make $YOUR_BOARD bootload
Makefile:109: warning: no BOARD specified, will fall back to BOARDPATH for arbitrary bsp locations
Makefile:117: warning: you have not defined COM_PORT. Assuming it is COM4
Makefile:121: warning: you have not defined PYTHON3. assuming it is accessible by 'python3'
Makefile:125: defaulting to 115200 baud for ASB
Makefile:129: defaulting to 921600 baud for SVL
Makefile:134: warning: you have not defined SDKPATH so will continue assuming that the SDK root is at ../../../../..
Makefile:142: warning: you have not defined COMMONPATH so will continue assuming that the COMMON root is at ../../../../common
Makefile:149: *** Error: BOARDPATH must be provided. Stop.

I've been make ing with sdk 2.2 successfully for a couple of months now...same computer, toolchain, etc. Followed the Getting started from
Then follow these steps

Originally raised by a user of the SparkFun BSPs repo: FreeRTOS example code clock-rate error?

Many FreeRTOS example files use this FreeRTOSConfig.h preprocessor definition of clock speed:

#ifdef AM_PART_APOLLO2
    #define configCPU_CLOCK_HZ                  48000000UL
#else
    #define configCPU_CLOCK_HZ                  24000000UL
#endif

This suggests that the Apollo2 runs at 48 MHz and anything else runs at 24 MHz. Since the Apollo2, Apollo3, and possibly other future boards run at 48 MHz this could/would cause timing errors within FreeRTOS. A suggested fix is to replace all those definitions with this alternate which more accurately reflects the default clock settings for Ambiq Apollo MCUs:

#ifdef AM_PART_APOLLO
    #define configCPU_CLOCK_HZ                  24000000UL
#else
    #define configCPU_CLOCK_HZ                  48000000UL
#endif

Hi, I have been exploring this reporsitory but not able to find SD card demo, please can u share a link if its already a part of it and if not please share a plan to public.

Thanks!

Modified the tflite-micro hello_world example using the library, and now receive the following error when trying to flash the compiled binary to the SparkFun Edge:

Connecting with Corvette over serial port /dev/ttyUSB0...
Sending Hello.
Received response for Hello
Received Unknown Message
msgType = 0x8080
Length = 0x8000
['0x80', '0x80', '0x0', '0x80', '0x80', '0x80', '0x0', '0x80', '0x0', '0x80', '0x80', '0x80', '0x80', '0x80', '0x80', '0x80', '0x80', '0x0', '0x80', '0x0', '0x80', '0x0', '0x0', '0x0', '0x80', '0x80', '0x80', '0x0', '0x80', '0x0', '0x0', '0x0', '0x80', '0x0', '0x80', '0x0', '0x0', '0x0', '0x80', '0x0', '0x80', '0x80', '0x80', '0x0', '0x80', '0x80', '0x80', '0x0', '0x80', '0x0', '0x0', '0x80', '0x0', '0x0', '0x0', '0x80', '0x80', '0x0', '0x0', '0x0', '0x0', '0x0', '0x80', '0x80', '0x80', '0x80', '0x80', '0x0', '0x80', '0x0', '0x0', '0x0', '0x80', '0x0', '0x80', '0x80', '0x0', '0x0', '0x80', '0x0', '0x0', '0x80', '0x80', '0x80', '0x80', '0x0', '0x80', '0x80']
!!!Wired Upgrade Unsuccessful!!!....Terminating the script

The values used in am_hal_uart.h for AM_HAL_UART_FLOW_CTRL_CTS_ONLY and AM_HAL_UART_FLOW_CTRL_RTS_ONLY (UART_CR_CTSEN_Msk and UART_CR_RTSEN_Msk respectively) are undefined.

We believe that the proper values to use are UART0_CR_CTSEN_Msk and UART0_CR_RTSEN_Msk. This follows the pattern of using the 0th instance of a peripheral as a template to configure other instances.

#13 patches this

The HAL provided IOM API does not handle arbitrary clock frequencies, though it could.

mcu/apollo3/hal/am_hal_pin.h has a few omissions and typos.
(verified against Apollo3 datasheet v_0_11_0 and confirmed with Ambiq - will be fixed in the next SDK release):

• pin 2 missing #define AM_HAL_PIN_2_UART1RX (0)
• pin 4 incorrectly states which UART module is muxed to function select 5.
  • should be: #define AM_HAL_PIN_4_UART1RX (5)
• pin 10 missing #define AM_HAL_PIN_10_UART1TX (0)
• pin 44 incorrectly stated as having M5nCE6 capabilities where it should have UART0TX.
  • should be: #define AM_HAL_PIN_44_UART0TX (6)

Some type definitions in apollo3.h use the identifier OVERFLOW however when it has already been defined as a numeric constant (for example by math library headers) this error arises:

error: expected unqualified-id before numeric constant

One potential solution is to undefine OVERFLOW if it is defined when apollo3.h is included.
This solution may have been instituted in the past: e346c6f

However that solution left OVERFLOW undefined. The new solution in 2.4.2-patch-fullduplex-spi stores the previous value of OVERFLOW and restores it at the end of the file

the common examples of board_sfe is old than the SDK version. So All makefile should be updated such as below:

INCLUDES = -I$(SDKPATH)/utils
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-host/sources/stack/l2c
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-profiles/sources/profiles/hid
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-profiles/sources/profiles/fmpl
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-host/sources/stack/att
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-profiles/sources/profiles/uribeacon
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-profiles/sources/apps
INCLUDES+= -I$(SDKPATH)/third_party/exactle/ble-profiles/sources/profiles/gap

The exactle is cordio in SDK 2.5.1. This issue will cause the example compile fail.

Several times the need to enable interrupts on a pin without removing the existing configuration has arisen. The pin configuration functions currently available in the SDK will wipe out the old configuration. A patch is provided in 2.4.2-patch-partial-pinconfig

There are many ways to accomplish the partial configuration required. The method in the patch was a quick solution. Other solutions might integrate better with the existing pin configuration methods.

The MSPI13 -> MSPI3 typo fix that was made in version 2.5.1 of the Ambiq SDK 2.5.1, section 6, Boards and BSP

5. Correct a typo in apollo3_evb BSP am_bsp_pins.c for AM_HAL_PIN_23_MSPI3 (was
   AM_HAL_PIN_23_MSPI13).

has been fixed in the BSP repo: sparkfun/SparkFun_Apollo3_AmbiqSuite_BSPs@6966d4c
however the boards_sfe submodule of this repository (for the 2.5.1 series branches) needs to be updated to include them, to fix this compile error:

AmbiqSuiteSDK/boards_sfe/redboard_artemis_atp/bsp/am_bsp_pins.c:684:28: error: 'AM_HAL_PIN_23_MSPI13' undeclared here (not in a function); did you mean 'AM_HAL_PIN_23_MSPI3'?
  684 |     .uFuncSel            = AM_HAL_PIN_23_MSPI13,
      |                            ^~~~~~~~~~~~~~~~~~~~
      |                            AM_HAL_PIN_23_MSPI3
*** [.pio/build/SparkFun_RedBoard_Artemis_ATP/Variant/bsp/am_bsp_pins.o] Error 1

See code below:

void
am_hal_triple_read(uint32_t u32TimerAddr, uint32_t ui32Data[])
{
  __asm (
    " push  {R1, R4}\n"
    " mrs   R4, PRIMASK\n"
    " cpsid i\n"
    " nop\n"
    " ldr   R1, [R0, #0]\n"
    " ldr   R2, [R0, #0]\n"
    " ldr   R3, [R0, #0]\n"
    " msr   PRIMASK, r4\n"
    " pop   {R0, R4}\n"
    " str   R1, [R0, #0]\n"
    " str   R2, [R0, #4]\n"
    " str   R3, [R0, #8]\n"
    :
    : [u32TimerAddr] "r" (u32TimerAddr),
      [u32Data] "r" (&u32Data[0])
    : "r0", "r1", "r2", "r3", "r4"
  );
}

ui32Data is the variable name passed into the function.
u32Data is the name of the variable used in the function.

Change them to the same name to fix compilation errors.

The header file hci_drv_apollo3.h (located in third_party/exactle/ble-host/sources/hci/ambiq/apollo3/) is missing C++ extern "C" guards. This makes it more difficult to use this interface from C++ sources.

A patch is available in branch 2.4.2-patch-cpp-guards-hci-drv-apollo3-h
The patch is included in the current master branch as well.

Quick Steps to Reproduce:

    am_hal_stimer_config(AM_HAL_STIMER_CFG_CLEAR | AM_HAL_STIMER_CFG_FREEZE);
    am_hal_stimer_config(AM_HAL_STIMER_HFRC_3MHZ);
    am_hal_stimer_int_enable(AM_HAL_STIMER_INT_COMPAREA);
    am_hal_stimer_compare_delta_set(0, 50000);

• observe no interrupt fired

Description
There are 2 bits that need to be set in order to actually enable sTimer compare interrupts
One is in STCFG, the other is in STMINTEN. The HAL only provides access to STMINTEN, thus you cannot enable sTimer Compare Interrupts using just the HAL.

So for example, if you wanted to use Compare A you would need to set both bit 8 of STCFG:

And bit 0 of STMINTEN:

Calling:

am_hal_stimer_int_enable(AM_HAL_STIMER_INT_COMPAREA);

Allows user to set STMINTEN, but the HAL provides no way of setting the bit in STCFG.

void
am_hal_stimer_int_enable(uint32_t ui32Interrupt)
{
    //
    // Enable the interrupt at the module level.
    //
    CTIMERn(0)->STMINTEN |= ui32Interrupt;
}

In am_hal_stimer_compare_delta_set() we see:

CTIMER->STCFG |= cfgVal & (AM_HAL_STIMER_CFG_COMPARE_A_ENABLE << ui32CmprInstance);

However, since it is masked with its starting value, the bit is never set.

Suggestions:

• Set the bit in am_hal_stimer_compare_delta_set() regardless of starting value
• Set the appropriate bit in am_hal_stimer_int_enable()

In release 2.4.2 some SPI full duplex functionality was removed. One function definition was removed from mcu/apollo3/hal/am_hal_iom.c (though the declaration remained in mcu/apollo3/hal/am_hal_iom.h) along with two enumeration values from am_hal_iom_dir_e and am_hal_iom_request_e types.

uint32_t am_hal_iom_spi_blocking_fullduplex(void *pHandle, am_hal_iom_transfer_t *psTransaction)
typedef enum { AM_HAL_IOM_FULLDUPLEX } am_hal_iom_dir_e;
typedef enum { AM_HAL_IOM_REQ_SPI_FULLDUPLEX } am_hal_iom_request_e;

patched by: 2.4.2-patch-fullduplex-spi

Anontmous bitfields should not have qualifiers and generate errors with the armc6 compiler.

__IM uint32_t : 1;
should be changed to
uint32_t : 1;

Ambiq released SDK 3.0.0 some months ago, which is the latest for the Apollo3 family.

The hookup guide for the Edge board is for V2.4.2. Some prerequisites have newer versions, so one has to be intuitive while following the hookup guide. Would be nice to upgrade the the guide and this repo for V3.0.0 of AmbiqSuite.

After copying the SFE board BSP files and also the ASB uploader i can confirm blinky examples runs well on the new SDK version.

Looking for a good example on how to use the IOM HAL to implement an I2C master, I found ios_lram_host.c. That one has a (minor) bug. Given that Ambiq doesn't seem to have a good issue tracker, I report that bug here instead. Maybe this repo can evolve into a community maintained, better quality SDK?

The example contains the following lines within the function iom_set_up:

    // Enable interrupts for NB send to work
    am_hal_iom_interrupt_enable(g_IOMHandle, 0xFF);

"NB" most likely refers to "non-blocking".
However, it turns our that am_hal_iom_interrupt_enable refuses the 0xFF, because the FIFO interrupt "shall not be used" (so the function source sais).
It seems that the HAL methods for non-blocking transfers do a lot of interrupt managing anyway, so most likely, it's simply not true that interrupts need to be enabled.
While this issue is inconsequential in the example, it is confusing for anyone trying to write high-quality code which does actually check error codes.

am_util_regdump.c uses several symbols that are not available for the Apollo3.

• AM_REG_ITM_NUM_MODULES and AM_REG_ITMn(n)
• AM_REG_NVIC_NUM_MODULES and AM_REG_NVICn(n)
• AM_REG_SYSCTRL_NUM_MODULES and AM_REG_SYSCTRLn(n)
• AM_REG_SYSTICK_NUM_MODULES and AM_REG_SYSTICKn(n)
• AM_REG_TPIU_NUM_MODULES and AM_REG_TPIUn(n)

Since the utility functions can be used by any version Apollo chip (Apollo, Apollo2, Apollo3, Apollo3p) the solution is most likely to provide these symbols for in the Apollo3 mcu/apollo3 dir. Other Apollo devices contain these definitions in the following files:

• am_reg_itm.h
• am_reg_nvic.h
• am_reg_sysctrl.h
• am_reg_systick.h
• am_reg_tpiu.h

None of which currently exist for apollo3