BSP fails to build for FreeRTOS on a Nios V with UART

[Andrew099]

I have a Nios V on a Max 10 with a UART (RS-232 Serial Port) Intel FPGA IP (and also JTAG UART). When I opened up the BSP editor, I selected FreeRTOS and went with all the defaults and made a BSP. However, when I try building a bare bones hello world C program, the BSP fails to build. It says that the BSP source file altera_avalon_uart_init.c has OS_FLAG_SET as undeclared, and similarly, it says the BSP file altera_avalon_uart_read.c has OS_FLAG_WAIT_SET_ANY undeclared. Also, altera_avalon_uart_write.c has OS_FLAG_CONSUME undeclared. How do I get the BSP to build?

I can use UART with HAL rather than FreeRTOS, and it works fine for the Nios V.

(I am using Quartus 23.1 STD.)

[EBERLAZARE_I_Intel]

Hi,

Can you share the files, I would like replicate this on my side.

[Andrew099]

Sure, I attached a Quartus archive of an example where the BSP won't build.

The C file doesn't have to have any substance to it. The following is fine:

// main.c
int main() {
   return 0;
}

1. Open the Quartus project using Quartus 23.1 STD, and compile it.
2. Create a BSP:
   • enter a niosv shell and open the BSP editor
   • select the sopcinfo file
   • select FreeRTOS
   • go with all other defaults
   • generate
3. Use the niosv-app to create a cmake file.
4. Run cmake and then make. (I'm using Linux.)

[EBERLAZARE_I_Intel]

Hi,

Thanks a lot for the info provided, let me test this on our side.

Also, could you provide the Quartus build version? You can find this in the "Help" tab in Quartus.

[andy25]

mailbox_simple doesnt compile either:

/projects/c5_nios/software/freertos_bsp/drivers/src/altera_avalon_mailbox_simple.c:36:10: fatal error: nios2.h: No such file or directory
   36 | #include "nios2.h"
      |          ^~~~~~~~~

This is FreeRTOS for NiosV Quartus Prime Lite 23.1 Build 991.

[Andrew099]

Thanks. I'm using Quartus Pime Version 23.1std.0 Build 991 11/28/2023 SC Standard Edition

[EBERLAZARE_I_Intel]

Hi,

I am a bit caught up on my side, I will try to get the test in the next few days.

Thank you for your patience, I shall get back to you soon.

[andy25]

"On-Chip Flash Intel FPGA IP" doesnt compile either:

In file included from freertos_bsp/drivers/src/altera_onchip_flash.c:32:
freertos_bsp/drivers/src/altera_onchip_flash.c: In function 'alt_onchip_flash_erase_block':
freertos_bsp/HAL/inc/io.h:126:34: error: expected expression before 'do'
  126 | #define SWIO(BASE, OFFSET, DATA) do {                   \
      |                                  ^~

[Broddo]

I've experienced this one as well. The reason is that the do {} while(0) is surrounded by a brace due to the macro expansion in altera_onchip_flash_regs.h

You can fix it by modifying each of the macros altera_onchip_flash_regs.h and removing the outermost brackets like so:

Old:

#define ALTERA_ONCHIP_FLASH_ENABLE_WRITE_AND_ERASE_OPERATION(base)              \
    (                                                                           \
        IOWR_ALTERA_ONCHIP_FLASH_CONTROL((base),                                \
            (IORD_ALTERA_ONCHIP_FLASH_CONTROL((base))                           \
            &                                                                   \
                ~(                                                              \
                    ALTERA_ONCHIP_FLASH_CONTROL_ALLSECTOR_WRITE_PROTECT_MSK |   \
                    ALTERA_ONCHIP_FLASH_CONTROL_PAGE_ERASE_MSK |                \
                    ALTERA_ONCHIP_FLASH_CONTROL_SECTOR_ERASE_MSK                \
                )                                                               \
            )                                                                   \
            |                                                                   \
                (                                                               \
                    ALTERA_ONCHIP_FLASH_CONTROL_ALLSECTOR_WRITE_ENABLE |        \
                    ALTERA_ONCHIP_FLASH_CONTROL_PAGE_ERASE_NOT_SET |            \
                    ALTERA_ONCHIP_FLASH_CONTROL_SECTOR_ERASE_NOT_SET            \
                )                                                               \
        )                                                                       \
    )

Modified:

#define ALTERA_ONCHIP_FLASH_ENABLE_WRITE_AND_ERASE_OPERATION(base)              \
        IOWR_ALTERA_ONCHIP_FLASH_CONTROL((base),                                \
            (IORD_ALTERA_ONCHIP_FLASH_CONTROL((base))                           \
            &                                                                   \
                ~(                                                              \
                    ALTERA_ONCHIP_FLASH_CONTROL_ALLSECTOR_WRITE_PROTECT_MSK |   \
                    ALTERA_ONCHIP_FLASH_CONTROL_PAGE_ERASE_MSK |                \
                    ALTERA_ONCHIP_FLASH_CONTROL_SECTOR_ERASE_MSK                \
                )                                                               \
            )                                                                   \
            |                                                                   \
                (                                                               \
                    ALTERA_ONCHIP_FLASH_CONTROL_ALLSECTOR_WRITE_ENABLE |        \
                    ALTERA_ONCHIP_FLASH_CONTROL_PAGE_ERASE_NOT_SET |            \
                    ALTERA_ONCHIP_FLASH_CONTROL_SECTOR_ERASE_NOT_SET            \
                )                                                               \
        )                                                                       \

 @EBERLAZARE_I_Intel Can you flag this to be patched as well? And any news on when the UART fix will be submitted? This is affecting me also. 

[EBERLAZARE_I_Intel]

Hi,

Thanks for the feedback, I was able to replicate the issue, I will channel this to our internal team.

I will update to you once we have any new info on this.

Thank you for your patience.

[andy25]

The lightweight uart has the same problem.

[Andrew099]

Okay, thank you for looking into it, and yes, please do let me know when you have more info on it.

[EBERLAZARE_I_Intel]

Hi,

We are still working on a patch fix for 23.1 std, I will check again if that will include for 23.1 std lite.

[EBERLAZARE_I_Intel]

Hi,

We are still working on a proper fix for this. We will update to you soon.

[EBERLAZARE_I_Intel]

Hi,

The changes for this error is to change the driver's code "\software\freertos_bsp\drivers\src"and modify the LW_UART HAL API as such (a KDB for this will be published):

• intel_lw_uart_init.c

• intel_lw_uart_read.c

• intel_lw_uart_write.c

However, for MAX 10, making this changes will increase the size of the .elf, and it would not fit the maximum size for MAX 10's OCRAM due to its size. Thus we regret to inform you, that MAX 10 cannot support FreeRTOS due to its memory limitation. You may continue with the Altera HAL or in the future consider a bigger FPGA.

[Andrew099]

I also can't click your images/links.

[Broddo]

The reason for the large execution size is due to the sneaky call to printf() in the provided vApplicationStackOverflowHook in FreeRTOS:

void vApplicationStackOverflowHook( TaskHandle_t xTask, char *pcTaskName )
{
    /*  To suspress unused argument warning. */
	( void ) xTask;

    printf("Stack overflow task is %s \r\n",pcTaskName);
    taskDISABLE_INTERRUPTS();
    __asm volatile( "ebreak" );
    for( ;; );
}

This pulls in large chunks of the standard library and completely bloats the code. Simply disabling the stack overflow check in the BSP is enough to shrink the code size enough to fit in the OCRAM on a MAX10 no problem. I'd suggest removing this and using one of the ALT_LOG functions going forward.  

[andy25]

all of your links are broken

[EBERLAZARE_I_Intel]

Let me try to reattach:

• intel_lw_uart_init.c

• intel_lw_uart_read.c

• intel_lw_uart_write.c

Again, for MAX 10, making this changes will increase the size of the .elf, and it would not fit the maximum size for MAX 10's OCRAM due to its size. You may continue to use Altera HAL or in the future consider a bigger FPGA.

[EBERLAZARE_I_Intel · Accepted solution]

In the "freertos/drivers/src/":

• intel_lw_uart_init.c
  • line 228~:

if (sp->tx_start == ((sp->tx_end + 1) & ALT_AVALON_UART_BUF_MSK))

   { 

    ALT_FLAG_POST (sp->events, 

            ALT_UART_WRITE_RDY,

            ALT_FLAG_SET);

   }

• intel_lw_uart_read.c
  • line 205~:

 ALT_FLAG_PEND (sp->events, 

           ALT_UART_READ_RDY,

           ALT_FLAG_WAIT_SET_ANY_WITH_CONSUME,

ALT_FLAG_WAIT_MAX_TIMEOUT);

• intel_lw_uart_write.c
  • line 192~:

 ALT_FLAG_PEND (sp->events, 

             ALT_UART_WRITE_RDY,

             ALT_FLAG_WAIT_SET_ANY_WITH_CONSUME,

             ALT_FLAG_WAIT_MAX_TIMEOUT);

[EBERLAZARE_I_Intel]

Hi Andrew,

We apologize for any inconvenience. Given this, is it okay to proceed with the Altera HAL with your design? Or do you have other FPGA?