Coder Social home page Coder Social logo

fsp's Introduction

Overview

Flexible Software Package (FSP) for Renesas RA MCU Family

FSP is the next generation Arm® MCU software package from Renesas, that enables secure devices and IoT connectivity through production ready peripheral drivers, Azure RTOS or FreeRTOS, and portable middleware stacks. FSP includes best-in-class HAL drivers with high performance and low memory footprint. Middleware stacks with Azure RTOS and FreeRTOS integration are included to ease implementation of complex modules like communication and security. The e² studio ISDE provides support with intuitive configurators and intelligent code generation to make programming and debugging easier and faster.

FSP uses an open software ecosystem and provides flexibility in using your preferred RTOS, legacy code, and third-party ecosystem solutions.

Current Release

FSP v5.4.0

Supported RA MCU Kits

  • AIK-RA6M3
  • AIK-RA4E1
  • BGK-RA6E2
  • CK-RA6M5
  • CK-RA6M5 V2
  • FPB-RA0E1
  • FPB-RA2E1
  • FPB-RA2E2
  • FPB-RA2E3
  • FPB-RA4E1
  • FPB-RA4E2
  • FPB-RA4T1
  • FPB-RA6E1
  • FPB-RA6E2
  • FPB-RA6T3
  • EK-RA2A1
  • EK-RA2A2
  • EK-RA2E1
  • EK-RA2E2
  • EK-RA2L1
  • EK-RA4E2
  • EK-RA4M1
  • EK-RA4M2
  • EK-RA4M3
  • EK-RA4W1
  • EK-RA6E2
  • EK-RA6M1
  • EK-RA6M2
  • EK-RA6M3
  • EK-RA6M3G
  • EK-RA6M4
  • EK-RA6M5
  • EK-RA8D1
  • EK-RA8M1
  • MCK-RA4T1
  • MCK-RA6T2
  • MCK-RA6T3
  • MCK-RA8T1
  • RSSK-RA2L1
  • RSSK-RA6T1

Supported Software Packaged with FSP

For a list of software modules packaged with FSP, see Supported Software.

Important Notice Regarding Azure RTOS

On November 21, 2023, Microsoft announced that they have decided to contribute Azure RTOS to open source under the stewardship of the Eclipse foundation and Azure RTOS will become Eclipse ThreadX. For detailed information, please refer to the announcement at Microsoft Contributes Azure RTOS to Open Source.

The support strategy scheme for Eclipse ThreadX will be determined and communicated at a later date. Microsoft will discontinue the Azure RTOS and Azure RTOS Middleware under the existing agreement LICENSED-HARDWARE.txt.

It is important to note that updates for Azure RTOS on these hardware will no longer be provided.

Product Security Advisories

Product Security Advisories for FSP and third party software (where available) are tagged with the 'product_security_advisory' label. Please check these issues for information from the respective vendors for affected versions and a recommended workaround or patch upgrade.

Known Issues

Visit GitHub Issues for this project.

Critical issues that cause an MCU to operate out of the hardware manual documented specifications are tagged with the 'critical' label. Please check critical issues before going to production for a workaround or recommended patch upgrade.

Setup Instructions

For existing users that are using FSP with e² studio

  • FSP versions of 2.0.0 and later require a minimum e² studio version of 2020-10.
  • FSP versions of 2.3.0 and later require a minimum e² studio version of 2021-01.
  • FSP versions of 3.0.0 and later require a minimum e² studio version of 2021-04.
  • FSP versions of 3.2.0 and later require a minimum e² studio version of 2021-07.
  • FSP versions of 3.4.0 and later require a minimum e² studio version of 2021-10.
  • FSP versions of 3.6.0 and later require a minimum e² studio version of 2022-01.
  • FSP versions of 3.7.0 and later require a minimum e² studio version of 2022-04.
  • FSP versions of 4.0.0 and later require a minimum e² studio version of 2022-07.
  • FSP versions of 4.1.0 and later require a minimum e² studio version of 2022-10.
  • FSP versions of 4.3.0 and later require a minimum e² studio version of 2023-01.
  • FSP versions of 4.4.0 and later require a minimum e² studio version of 2023-04.
  • FSP versions of 4.6.0 and later require a minimum e² studio version of 2023-07.
  • FSP versions of 5.0.0 and later require a minimum e² studio version of 2023-10.
  • FSP versions of 5.2.0 and later require a minimum e² studio version of 2024-01.1.
  • FSP versions of 5.3.0 and later require a minimum e² studio version of 2024-04.

If you have already installed a previous FSP release that included e² studio then you can download the packs separately. These are available for download under the Assets section for each release. There is a zipped version, FSP_Packs_<version>.zip, that will work on any supported OS. There is also a self-extracting installer version, FSP_Packs_<version>.exe, that will work on Windows.

When using the zipped version of the packs the zip file should be extracted into the e² studio support area. This directory is typically found under the user's home directory with a path such as ~/.eclipse/com.renesas.platform_2047834950. The number on the end of the path is unique to each e² studio installation. If you have two e² studio installations then you will have two directories with names of the format ~/.eclipse/com.renesas.platform_<unique_number>. Please note that e² studio must have been run at least once for this directory to be created. You can find the support area for a particular e² studio installation by clicking Help >> About e² studio. In the window that pops up click Installation Details and choose the Support Folders tab. The e² studio support area path will be shown.

For new users that are using FSP with e² studio

  1. Download the FSP with e² studio Installer from the Assets section of the current release.
  2. Run the installer. This will install the e² studio tool, FSP packs, GCC toolchain and other tools required to use this software. No additional installations are required.

If using RA Smart Configurator (RASC) with IAR Embedded Workbench or Keil MDK

  1. See RASC User Guide for MDK and IAR.

Starting Development

  1. Open e² studio and click File > New > C/C++ Project.
  2. In the window that pops up, choose Renesas RA in the left pane.

Related Links

FSP Releases : https://github.com/renesas/fsp/releases

FSP Documentation : https://renesas.github.io/fsp

FSP Webpage: www.renesas.com/ra/fsp

RA Product Information: www.renesas.com/ra

RA Product Support Forum: www.renesas.com/ra/forum

e² studio : www.renesas.com/e2studio

Example Projects : https://github.com/renesas/ra-fsp-examples

Knowledge Base: https://en-support.renesas.com/knowledgeBase/category/31087

Support: www.renesas.com/support

fsp's People

Contributors

bogdanthegeek avatar dsmith9000 avatar gsokoll avatar hwmaier avatar italomarsili avatar jadefds avatar jgeudens avatar kjassmann-renesas avatar liux-pro avatar michaelthomasj avatar renesas-abigail avatar renesas-austin-hansen avatar renesas-brandon-hussey avatar renesas-fsp-development avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

fsp's Issues

Default XTAL value incorrect on EK-RA2E1

Issue

The default XTAL (ie: main clock oscillator) value when creating a project for the EK-RA2E1 is 16MHz. The EK-RA2E1 board actually has a 20MHz XTAL. Please note that the default clock source for EK-RA2E1 projects is the 48MHz HOCO. This means that changing the XTAL value will not impact projects unless the clock source is changed to choose the XTAL.

Workaround

The XTAL frequency can be modified manually in the Clocks tab of the RA Configurator.

  1. Click on the Clocks tab.
  2. Click on the "XTAL 16MHz" text box.
  3. Type in "20000000" and press Enter.

ek_ra2l1_xtal

Must force hardware reset with IAR EW to pick up correct reset vector

Issue

When using the default debug settings for an IAR EWARM non-secure project the reset vector may not be chosen correctly.

Workaround

When debugging a non-secure project in IAR EWARM, it is necessary to force a hardware reset to pick up the correct reset vector. This can be done by adding the following to the Options | Debugger | Extra Options dialog in EWARM: --drv_vector_table_base=0x0

image

Renesas Smart Configurator generates invalid data for ACMPLP1

Describe the bug
Using the Renesas Smart Configurator for RA2A1 and creating a stack for low power analog comparator 1 result invalid data in config structure.
If you select:

  • CMPIN1 (channel 1 only) for Analog Input Voltage Source
  • CMPREF1 (channel 1 only) for Reference Voltage Input Source

the generator selects a value from enum, which is not allowed for RA2A1 controller.
Also in initialisation function of FSP R_ACMPLP_Open() the value will be set wrong, because the driver will shift the value by 4.

To Reproduce
Steps to reproduce the behavior:

  1. Open Renesas Smart Configurator

  2. Create a new stack for low power analog comparator

  3. Use following values:
    RSC_LPACMP_Settings

  4. Press create

  5. Check hal_data.c
    RSC_created_code

RSC_defines

Expected behavior
I think the value should be 1 and not 4, because the allowed register values of ACMPLP.COMP0SEL and ACMPLP.COMP1SEL are:

  • 0b00
  • 0b01
  • 0b10

Also the value for channel 1 is shifted by 4 in initialisation routine.

Desktop

  • Windows 10 19093
  • RA Smart Configurator Version: 7.8.0.R20200321-2326
  • IAR Embedded Workbench for Arm 8.50.1

High temperature LGA/BGA packages for RA6M1, RA6M2, and RA6M3 not available during project creation

Issue

The following part numbers are not available during project creation:

  • R7FA6M1AD3CLJ
  • R7FA6M2AF3CLK
  • R7FA6M2AD3CLK
  • R7FA6M3AH3CLK
  • R7FA6M3AF3CLK
  • R7FA6M3AH3CBG
  • R7FA6M3AF3CBG

Workaround

Select the part number with a 2 instead of a 3 in the 4th character from the end. For example, to create a project for R7FA6M1AD3CLJ, select R7FA6M1AD2CLJ. The version with a 2 is functionally identical except for the operating temperature range.

Stack overflow may not be caught in FreeRTOS projects on devices that support TrustZone

Issue

In a TrustZone non-secure FreeRTOS project, if a stack overflow occurs in the PendSV_Handler (which adds up to 40 bytes to the stack), it does not generate an STKOF UsageFault.

In a flat FreeRTOS project on MCUs that support TrustZone, stack overflows of the process stack do not generate an STKOF UsageFault.

Workaround

Allocate at least 40 bytes more for the stack than the maximum stack used by the thread.

SD/MMC Host Interface (r_sdhi) - Card Detect interrupt flags can be set while interface is closed

Issue

When card detection is configured to "CD Pin" in the in the RA Configuration editor, card detection is enabled during R_SDHI_Open(). After closing the interface via R_SDHI_Close(), card detection interrupt processing will not occur, but interrupt flags can still be set. This can cause ISR processing to occur, immediately after re-opening the r_sdhi interface for card insertion and removal events that took place while the interface was closed. In this case, it's possible that both the 'removed' and 'inserted' flags are set.

Workaround

R_SDHI_StatusGet() Should be used to initially determine the card state after opening the interface.
See "Card Detection Example" in FSP documentation: r-sdhi-examples

Incorrect generated value for digital_filter_stages in r_iic_slave

Issue

The digital_filter_stages variable is set to the value that should be in ICMR3 (one less than the nominal value). The driver expects the nominal value, and converts it again before writing ICMR3.

Workaround

Select a value of 1 more than the digital filter stages desired, or update iic_slave_extended_cfg_t before calling R_IIC_SLAVE_Open().

R_OSPI Write errors due to timing sensitivity

Issue

The R_OSPI module write function can fail silently when writing data. The chip select line is deasserted after a period of time defined by R_OSPI->DCSTR_b->DVSELHI and R_OSPI->DWCSTR_b->CTWW0, which ends the operation prematurely if the write is not completed. This can cause failure for slight timing variations caused by things such as unoptimized code, coverage builds, interrupt handling, preemption, etc. This issue is most apparent when writing more than a few bytes of data, but can occur for any amount of data.

Workaround

Verify data after all octaflash write operations by reading it back. If the write was unsuccessful, erase the block containing the first failure and repeat the write operation from the erased block.

Tolerance to variation in write timing can be improved by compiling with all 'speed optimizations' enabled, and setting the DVSELHI and CTWW0 registers to their maximum settings. Register settings can be configured in e2 Studio via Stacks Configuration:

  • Set General > Single Continuous Mode > Write Idle Time to the maximum value of 127.
  • Set Chip Select Timing Setting > Memory Mapped Write Pull-up Timing to the maximum value of 9 SPI/SOPI, 8.5 DOPI.
  • Place all calls to R_OSPI_Write() in critical sections to prevent interruption or preemption while writing to octaflash memory.

Migration Required

DMAC hardware acceleration is supported for OSPI writes in FSP 3.0.0. To ensure reliable OSPI writes:

  1. Add a Transfer Driver on r_dmac module as a dependency of OSPI Driver on r_ospi on the Stacks tab of the FSP Configuration tool.
  2. Enable DMAC Support in the Properties of OSPI Driver on r_ospi.

AC6 TrustZone non-secure Projects place ROM registers at the wrong address

Issue

AC6 TrustZone non-secure projects place non-secure Option-Setting Memory at the wrong address. This causes behavior for OFS1, BANKSEL, BPS, and PBPS to be undefined. This includes the following settings in the FSP Configuration editor:

  • OFS1 register settings > Voltage Detection 0 Circuit Start
  • OFS1 register settings > Voltage Detection 0 Level
  • OFS1 register settings > HOCO Oscillation Enable
  • Block Protection Settings (BPS) > BPS0
  • Block Protection Settings (BPS) > BPS1
  • Block Protection Settings (BPS) > BPS2
  • Permanent Block Protection Settings (PBPS) > PBPS0
  • Permanent Block Protection Settings (PBPS) > PBPS1
  • Permanent Block Protection Settings (PBPS) > PBPS2

Workaround

Add the following line at the top of script/fsp.scat after #include "memory_regions.scat":

#define OPTION_SETTING_START        0x0100A180
#define OPTION_SETTING_LENGTH       0x80

Fix

This is fixed in FSP v2.2.0 if the linker script is regenerated after the project is updated. To regenerate the linker script, rename script/fsp.scat to fsp_v2.1.0.scat, then click "Generate Project Content" in the FSP Configuration editor.

AGT can write outside bounds of array on RA6M4

Issue

In r_agt.c gp_prv_agt_periods is an array of length 2, that is indexed by channel number and written to whenever the period register is set. The RA6M4 has up to 6 channels.

Workaround

Use only channels 0 and 1 of AGT.

Linker error in TrustZone non-secure projects when building for RA4M3 or RA4M2 with IAR compiler

Issue

When building RA4M3 or RA4M2 TrustZone non-secure projects, the following linker error is output:

Error[Lc009]: "OSPI_DEVICE_0_START" undefined
Error[Lc009]: "OSPI_DEVICE_1_START" undefined

Workaround

In the secure application linker script (script/fsp.icf), add the following lines outside of any conditionals:

define exported symbol __tz_OSPI_DEVICE_0_N = OSPI_DEVICE_0_START;
define exported symbol __tz_OSPI_DEVICE_1_N = OSPI_DEVICE_1_START;

GUI_Exit() does not free all memory allocated by GUI_Init() in the emWin port

Issue

Memory allocated by Dave2D in GUI_Init() is not freed when GUI_Exit() is called.

Workaround

In ra/fsp/src/rm_emwin_port/LCDConf.c, add the following just below _GraphicsHWInit:

/*********************************************************************
 *
 *       _GraphicsHWDeInit
 */
static void _GraphicsHWDeInit (void)
{
    //
    // Stop graphics LCD controller
    //
    while (FSP_SUCCESS != R_GLCDC_Stop(_g_display_emwin->p_ctrl))
    {
        /* Wait for GLCDC register update to complete before closing driver. */
    }
    R_GLCDC_Close(_g_display_emwin->p_ctrl);
#if EMWIN_LCD_USE_DAVE
    //
    // Deinitialize D/AVE 2D driver
    //
    d2_freerenderbuffer(*_d2_handle_emwin, renderbuffer);
    d2_deinithw(*_d2_handle_emwin);
    d2_closedevice(*_d2_handle_emwin);
#endif
}

In the same file, add the following lines to LCD_X_Config() just after the call to _GraphicsHWInit:

    //
    // Set graphics HW deinit callback for GUI_Exit
    //
    static GUI_REGISTER_EXIT RegisterExit;
    RegisterExit.pfVoid = _GraphicsHWDeInit;
    GUI__RegisterExit(&RegisterExit);

Some modules cause a build error when no callback is provided

Issue

The following modules will not build when the callback symbol in the configuration editor is left at the default value ("NULL"):

  • r_iic_master
  • r_iic_slave
  • r_kint
  • r_sci_i2c
  • r_sci_spi
  • r_spi
  • rm_vee_flash

Workaround

Remove the erroneous callback prototype from the generated header file.

Pin configuration is not available for VREFH pin on RA2A1

Issue

VREFH pin is not available for configuration on RA2A1 device through the pin configurator.

Workaround

Use the R_IOPORT_PinCfg() function to configure VREFH pin (P013). Example function call:

R_IOPORT_PinCfg(&g_ioport_ctrl, BSP_IO_PORT_00_PIN_13, ((uint32_t) IOPORT_CFG_ANALOG_ENABLE));

HOCO frequency setting for OFS1_SEC register is not applied in Flat project for RA6M4

Issue

Issue description with steps to reproduce:

  1. Selected "CLKOUT Src: HOCO" in Clocks tab
  2. Changed "P611" settings from GPIO to CLKOUT in Pins tab
  3. Added CGC Driver in Stacks tab
  4. Added "R_CGC_Open(&g_cgc0_ctrl, &g_cgc0_cfg);" API in user code.

Actual result:

The monitored frequency of CLKOUT was 16MHz although HOCO 20MHz was set in clocks tab

Expected result:

The monitored frequency of CLKOUT is 20MHz

Note:
If user used Secure project, this issue was not reproduced. The reason is below.

[Secure Project]
The define value of "BSP_CFG_CLOCKS_SECURE" macro in bsp_clock_cfg.h is (1).
This value is reflected the setting of "Secure" button in clocks tab as shown in attached image below.
If BSP_CFG_CLOCKS_SECURE is (1), the value of OFS1_SEL (0x0100A280) was set for Secure Clock.

[Flat Project]
There is no "Secure" button in clocks tab.
The generated define value of "BSP_CFG_CLOCKS_SECURE" macro in bsp_clock_cfg.h is always (0).
In this case, the setting in OFS1 (0x0100_A180) was used although the value of user setting is programed in OFS1_SEC (0x0100_A200).

image

IAR build error when building TrustZone Secure projects with -Ol (low) optimization

Issue

When building TrustZone secure projects with the IAR compiler using -Ol (Low) optimization, there is a linker error from bsp_security.c. This is with IAR v8.50.6.

Workaround

Build with -Oh (High, Balanced) optimization. Select the project or the file bsp_security.c and select "High" and "Balanced" from Options | C/C++ Compiler | Optimizations. Check "Override inherited settings" to change the setting for bsp_security.c only.

Linker error when migrating AC6 TrustZone secure projects from FSP v2.1.0 to v2.2.0

Issue

When a TrustZone secure project built with Arm Compiler 6 is migrated from FSP v2.1.0 to FSP v2.2.0, the following linker errors are observed:

Error: L6218E: Undefined symbol Image$$__tz_ID_CODE_N$$Base (referred from bsp_security.o).
Error: L6218E: Undefined symbol Image$$__tz_ID_CODE_S$$Base (referred from bsp_security.o).
Error: L6218E: Undefined symbol Image$$__tz_OPTION_SETTING_N$$Base (referred from bsp_security.o).
Error: L6218E: Undefined symbol Image$$__tz_OPTION_SETTING_S$$Base (referred from bsp_security.o).
Error: L6218E: Undefined symbol Image$$__tz_OPTION_SETTING_S_N$$Base (referred from bsp_security.o).
Error: L6218E: Undefined symbol Image$$__tz_OPTION_SETTING_S_S$$Base (referred from bsp_security.o).

Workaround

To fix this, either regenerate the linker script (recommended) or update the linker script.

Regenerate the linker script

To regenerate the linker script, rename script/fsp.scat to script/fsp_v2.1.0.scat. Then click "Generate Project Content" in the FSP Configuration editor to pull in the linker script for FSP v2.2.0. If any modifications have been made to the FSP v2.1.0 linker script, add them to the newly generated script/fsp.scat file.

Update the linker script

To update script/fsp.scat (not required if the linker script has been regenerated), add the execution regions after the comment below in any LOAD_REGION (added to LOAD_REGION_OPTION_SETTING in the example below):

LOAD_REGION_OPTION_SETTING OPTION_SETTING_START OPTION_SETTING_LENGTH
{
  /* Add the following lines in any LOAD_REGION. */
  __tz_OPTION_SETTING_S OPTION_SETTING_START EMPTY 0
  {
  }

  __tz_OPTION_SETTING_N OPTION_SETTING_START + OPTION_SETTING_LENGTH EMPTY 0
  {
  }

  __tz_OPTION_SETTING_S_S 0 EMPTY 0
  {
  }

  __tz_OPTION_SETTING_S_N 0 EMPTY 0
  {
  }

  __tz_ID_CODE_S 0 EMPTY 0
  {
  }

  __tz_ID_CODE_N 0 EMPTY 0
  {
  }

VEEM can't define Reference data size > 0

Hallow!
works with RA2L1 project.
install VEEM on flash_lp.
enable reference data - it done well.
try set reference data size =2 - it not changes any way, always reset to 0.

is VEEM supports Reference data?

Low power analog comparator FSP function R_ACMPLP_Open() overwrites registers on RA2A1

When I use ACMPLP0 and ACMPLP1 and initialize both instances with R_ACMPLP_Open() the initialisation of second instance overwrites register for the first instance.
I use IAR EWBARM 8.5 with Renesas Smart Configurator plugin, but it can also reproduce with e² studio.

To Reproduce
My settings are for channel 0 and channe 1 are quite the same. Only for channel 1 the instance has the name ACOMP_VO2 and the selected channel is 1.
ACMPLP0_settings

As input for channel 1 the values for "Analog Input Voltage Source" and "Reference Voltage Input Source" are the same as for channel 0. This is a bug in Renesas Smart Configurator. I will open another issue for that.

  1. Create stack for ACMPLP0 with Renesas Smart Configurator
  2. Create stack for ACMPLP1 with Renesas Smart Configurator
  3. Open first instance of ACMPLP with R_ACMPLP_Open(&ACOMP_VO1, &ACOMP_VO1_cfg);
  4. Control registerset. Should be like this:
    ACMPLP_register_1st_call
  5. Open second instance of ACMPLP with R_ACMPLP_Open(&ACOMP_VO2, &ACOMP_VO2_cfg);
  6. Control registerset. In my opinion the registers for channel 0 shouldn't been touched, but:
    ACMPLP_register_2nd_call
  7. Now the comparators won't work, because the whole input selection is wrong.

Expected behavior
I thought, if I use both I can initialize the channels independent to each other. I created two stacks. One for channel 0 and one for channel 1.
If I set all needed registers directly over CMSIS, both comparators work fine.

I did an workaround to eliminate this problem by setting the lost register values of channel 0 after initialisation of channel 1:

R_ACMPLP->COMPSEL0_b.IVCMP0 = 0x01;
R_ACMPLP->COMPSEL0_b.IVCMP1 = 0x01;
R_ACMPLP->COMPSEL1_b.IVREF0 = 0x01;                                         
R_ACMPLP->COMPSEL1_b.IVREF1 = 0x01;                                         
R_ACMPLP->COMPSEL1_b.C1VRF2 = 1;

Desktop:

  • OS: Windows 10 1903
  • IAR Embedded Workbench for ARM 8.50.1
  • Evaluation board EK-RA2A1

Incorrect value written to FCACHE->FLWT register during startup on some MCUs.

Issue

BSP_FEATURE_BSP_SYS_CLOCK_FREQ_TWO_ROM_WAITS is set to 800Mhz instead of 80Mhz on the following MCUs:

  • RA6M1
  • RA6M2
  • RA6M3
  • RA6T1

As a result, if SystemCoreClock is configured to a value greater than 80Mhz, FCACHE->FLWT will be set to 1 wait state instead of the correct value which is 2 wait states.

On the following MCUs, FCACHE->FLWT is set to 2 wait states when only 1 wait state is supported:

  • RA4M3

Workaround

Apply the patch file to bsp_clocks.c

# from project root directory
patch -u ra/fsp/ra/src/bsp/mcu/all/bsp_clocks.c -i fix-<version>.patch

fix.zip

Flat (non-TrustZone) IAR EWARM projects always report device partitions as needing to be updated

Issue

When debugging a "flat" (non-TrustZone) project in IAR EWARM with a device that supports TrustZone, the device partition sizes are always reported as needing to be updated.

Workaround

This can be worked around by unchecking the "Use macro file(s)" check box in the Options | Debugger | Setup dialog in EWARM and setting device partition sizes manually (if required) with the Renesas Device Partition Manager from the Run menu in RA Smart Configurator (RASC).

image

image

QSPI QSPKCLK divisors >= 20 are off by 1

Issue

Dividers >= 20 for Bus Timing > QSPKCLK Divisor are off by 1. Also divisor of /19 is not a valid option.

Workaround

When selecting a divider >= 20 for Bus Timing > QSPKCLK Divisor, select the next available smaller divider. Do not select the maximum divider of 48.

PmSAR registers are incorrectly being set for non TrustZone parts

Issue

In SystemInit() , the follow should be in trustzone macros.

    /* Ensure that the PMSAR registers are reset (Soft reset does not reset PMSAR). */
    R_BSP_RegisterProtectDisable(BSP_REG_PROTECT_SAR);

    for (uint32_t i = 0; i < 9; i++)
    {
        R_PMISC->PMSAR[i].PMSAR = UINT16_MAX;
    }

    R_BSP_RegisterProtectEnable(BSP_REG_PROTECT_SAR);

Arm Stack Sealing vulnerability

Issue

Arm has disclosed a potential Armv8-M processor Secure software Stack Sealing vulnerability on 16th October 2020. More Info here.

According to ARM, the mitigation for this vulnerability is purely in software and is referred as stack sealing. It is only necessary in Armv8-M processors where the TrustZone security extension is being used, i.e. there is code running in both Secure and Non-secure states. No changes to hardware are required.

This will be fixed in the next FSP release.

OSPI Clock Source is Hardcoded to PLL2

Issue

The R_BSP_OctaclkUpdate() function takes a parameter that includes OSPI clock source configuration. This parameter is not used and the OSPI clock is always set to PLL2.

Workaround

This issue has no impact for applications using PLL2 as the clock source for OSPI. Therefore, if possible, it is recommended to use PLL2 until this issue is resolved.

BL2 random seed generation on boot

Issue

TFM used a hardcoded array as its seed. This does not meet the production requirement of having a random seed per device that should be updated on each boot.

RA4M2 programming failures when moving from TrustZone project to Flat project

Issue

When switching between a full TrustZone project and a Flat project (effectively disabling TrustZone) you may experience programming failures when using a SEGGER J-Link debugger. This issue has been encountered when using SEGGER J-Link v6.94 which is used with FSP v2.3.0.

Workaround

To rectify this please Initialize the Device Lifecycle Management (DLM) state back to factory default using the Renesas Device Partition Manager. This tool can be found in e2 studio, IAR Embedded Workbench, and Keil MDK.

In e2 studio perform the following:

  1. Click Run >> Renesas Device Partition Manager.
  2. Check the box next to Initialize device back to factory default. This option will erase any TrustZone boundaries that were previously programmed.

image

  1. Click Run.

BLE BD address cannot be set with R_BLE_VS_SetBdAddr()

Issue

The BLE BD address cannot be set using the R_BLE_VS_SetBdAddr() API.

Workaround

None. This feature is not available. The device address is set based on a previously stored address or a created from the MCU unique ID.

RA2L1 access toGPIO RR/SR only 16bit

Hallow!
i`ve tryed work with gpio.PCNTR3 as 32bit value - set and clear multiple pins at one time, some like eqivalents to write to port, but only selected bits.
And stucked that 32bit write to PCNTR3 does nothing.

    port->PCNTR3 = pins & mask; // this is not works

only 16bit access to PORR,POSR works.

    // this works well
    port->PORR   = ~data & bits_mask;
    port->POSR   = data & bits_mask;

what i do wrong?

Incorrect option in r_lpm configuration for Snooze End Sources for RA4W1

Issue

In the FSP Configuration tool for r_lpm on RA4W1, under Standby Options > Snooze End Sources, ADC1 Compare Mismatch should be ADC0 Compare Mismatch.

Workaround

To use ADC0 Compare Mismatch as a snooze end source on RA4W1, copy and update the generated lpm_cfg_t structure before calling R_LPM_Open().

Invalid chip address calculation by r_ospi during erase

Issue

r_ospi driver would calculate the relative chip address based on channel 0 only during the erase API call. Incorrect address is calculated for channel 1.

Workaround

Block and sector erase is not supported by the OSPI driver for channel 1 in the releases mentioned in the applies-to-* labels. If block and sector erase is required use channel 0 or upgrade to v2.3.0.

R_AGT: If timer stop is called inside user defined callback the timer will restart upon exiting callback

Issue

Any changes made to AGTCR inside a user defined callback for the selected channel will be overwritten when the callback returns to the AGT driver interrupt. As a result calling a function such as R_AGT_Stop() inside the user callback will have no effect and the timer will restart.

Workaround

Do not attempt to call any function that modifies AGTCR inside the user defined callback. This includes R_AGT_Start, R_AGT_Stop, R_AGT_Enable, and R_AGT_Disable.

USB interrupt priority and configMAX_SYSCALL_INTERRUPT_PRIORITY

Issue

The USB driver does not work properly when the USB interrupt priority level is higher priority than the configMAX_SYSCALL_INTERRUPT_PRIORITY macro value.

Workaround

Specify a lower priority for the USB interrupt priority than the configMAX_SYSCALL_INTERRUPT_PRIORITY macro value.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.