This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CCS/AM5718: Building custom board for RTOS

Part Number: AM5718

Tool/software: Code Composer Studio

Hi

SoC: AM5718
IDE: CCS  Version: 8.3.0.00009
For almost 2 weeks we have not even got a simple program like the hello world program to run on our target design PCB.
Our problem is extremly simple, we have a made our own PCB design (Board) with the SoC AM5718 and we have
used PinMux to define up the pheripals and pin layout.
We now want to use the output files from PinMux and create the needed CSL and LLD's layers for a RTOS project.
(We also guess that that "RTOS" as it is mentioned on wikis is actualy SYS/BIOS only aviable for the Linaro compiler)

We tried several ways to get this working, such as
software-dl.ti.com/.../index_how_to_guides.html
Where we copied the idkAM571x project (it included the same files that PinMux outout)
But no luck, our board does not show up on page 2 when creating a new CCS project.
Project->New CCS project
 Target: AM571x - Cortex A15, AM57158
 ProjectName: Test10
 Compiler version: GNU v7.2.1 (Linaro)
 SYS/BIOS/GNU Target Examples/Typical
Click next -> our board does not show up among the "platforms"

Neither of us have 10 years of core development inside Eclipse or of TI's development envionment but
unless the whole planet is only using evaluation boards our scenario, with a custom board can
not be new or even uncommon so people must have solved this before.

We assume that somehow the output files from PinMux can be reused (to build a custom board) therefore all
the CSL and LLD's are collected and created without any deeper knowledge of how the SoC is actually built up
or what addresses different registers are located at (noone who buy a evalution kit and fire" it up need to know this).
Our imagination is that

1. We define the pheripals in PinMux
2. Create/define a custom board (pkg, based on for example idkAM571x)
3. Start a new CCS project and select our custom board with RTOS
4. A project is created with a main function in which the predefined function Board_Init() do the intializasiation of the Soc and one 
process is created (like the taskFxn)
We expect to find and use functions like I2C_WriteData(address, data) "within" the project etc.
It is even acceptable that we have to set up interrupt and interrupt vectors (that is, for a small special use cases we have to read the RTM in depth).
 
Do anyone know a company that can solve this for us, that is,
create a board description file that reflects our pheripal's which can be used in the CCS when a new project is chosen.?
or have a link or helpful tips of how doing this, please help us, we can not be the first on the planet facing this.
If it is assumed that everyone should build everything up from bottom, it surely must be a guide somewhere describing
how to use the files from the PinMux tool, cherry pick CSL, LLD's from c:/ti/pdk_am57xx_1_0_13 tp and add RTOS 
to create your own project.
Please do not give the standard tips like
They all presume that you never heard of CPU's before, you are using a shelfware evaluation kit board or,
despite gigabyte's in sizes, is it not helpful for our use case.
Regards Stefan
  • Stefan,

    Sorry to know that the custom board porting for your project is not going as expected despite reviewing all the documentation that we have around this topic.  We are in the process of overhauling the Custom board port documentation and I would like to give you a preview and see if this helps. 

    Here is the typical development flow that we expect a user to create a custom BSP for their own platform:

    This flow has been put together based on the internal development flow that the TI team follows whenever we create a new platform that we need to add to the Processor SDK RTOS. For example AM571x IDK was created after AM572x EVM.

    Step 1: Before doing anything with the peripherals, can you let us know if you have a working GEL file with the updating clocking and DDR setup such that you can connect to all the cores and load and run simple hello world code from the cores. Other than GEL this should not require any porting.

    Step 2: When porting Processor SDK RTOS to custom platform, the CSL and driver, OSAL doesn`t need to be re-built as these are components that we provide which are not reliant on any external board configuration. All of the changes corresponding to your HW are consolidated in the Board library and that is where you should focus on.

    Some key things to take care of in the board library:

    1. The simpler approach to start would be to use existing TI platform that your HW resembles and update the source files directly in that folder and rebuild the board library.

    If you want to created your own board library you can create a separate folder and update the build as shown below:

    http://processors.wiki.ti.com/index.php/Adding_Custom_Board_Library_Target_to_Processor_SDK_RTOS_makefiles 

    2. TI HW has a personality EEPROM connect to I2C that provides version number, silicon revision and board ID for software to use. IF your board doesn`t use the personality EEPROM, please remove that code.

    3. Pinmux changes: After the pinmux project for your HW is generated, the source files for PDK are provided by the tool so you can simply drop those into board.

    In addition to this change, you need to ensure that the clock and the peripheral instances are updated in the _clock.c and the board_cfg.h file.

    4. DDR changes: Make sure you have tested the GEL file with updated clocking and EMIF Controller and PHY before updating the board library.  This is critical else the board_init for DDR will fail. while you figure this out, you can choose to run and test the HW using on chip OCRAM memory instead.

    Leverage the EMIF Tools that we provide to generate these settings.

    http://www.ti.com/tool/SITARA-DDR-CONFIG-TOOL 

    5. The first thing to check would be to use board diagnostics and check the interfaces for functionality. There are many useful tests like DDR mem test, GPIO, I2C EEPROM and SPI test that don`t use interrupts or DMA and are simple tests that we provide for HW checkout. This will also help confirm that the pinmux and clock chnages you made are as expected.

     6. You can then move to more advanced interfaces like CPSW, PCI, USB and check to see if your MDIO-PHY interface and USB device and host mode setup are working.

    Having said that if you are looking for a third party to help with this port, there are several partners that we work with that can help you with this effort that you can find from the list here:

    TI DEsign Network Resources

    Based on the region that you are based in and the type of service you can pick from the list.

    Regards,

    Rahul

    PS: I know that you indicated that you don`t want links to training and collateral as you are not looking for basic stuff. To skip basic information and go directly to the relevant section in the training, you can go directly to Section 9 of the training application development with processor SDK RTOS

  • Hi

    > We are in the process of overhauling the Custom board port documentation and I would like to give you a preview and see if this helps.
    Is that the new CCS platform release roumers?
    Is it in the ner future, that is, weeks, perhaps it is worth waiting for?
    > This flow has been put together based on the internal development flow that the TI team follows
    > can you let us know if you have a working GEL file with the updating clocking and DDR setup such that you can connect to all the cores
    >
    Our PCB have not arrived yet, it is under production, we are trying to create the board now and dry code a little bit
    to be ahead of time.

    > All of the changes corresponding to your HW are consolidated in the Board library and that is where you should focus on.
    That is in the catalouge we create under ?
    ..../ti/pdk_am57xx_1_0_13/packages/ti/board/src/CustomBoard

    > The simpler approach to start would be to use existing TI platform
    We took idkAM57x as a baseline
    The strange thing in both description is the line
    CFLAGS_GLOBAL_customAM572x  = -DSOC_AM572x -DevmAM572x
    Should not
    CFLAGS_GLOBAL_customAM572x
    be
    CFLAGS_GLOBAL_customBoard
    in line with the other text ?

    We also assume that the lines
    ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
      PLATFORM_XDC = "evmAM572XCustom"
    endif
    Makes it visible in the CCS gui when creating new (RTOS, SYS/BIOS) project, that is, even if our board/package is using 'myCustomBoard' in file names and in makefiles it will be
    listed as 'evmAM572XCustom' in the GUI.

    > 3. Pinmux changes: After the pinmux project for your HW is generated, the source files for PDK are provided by the tool so you can simply drop those into board.
    Here is another strange thing we can not sort out, already in the idk571x folder there is both the file idkAM571x_pinmux and the files
    generated from the PinMux tool (boardPadDelayDevice.c, boardPadDelay.h), is not the PinMux files used in the build ?
    We have assumed that we just dropp the PinMux files into the directory and they are "used" in the build.

     >In addition to this change, you need to ensure that the clock and the peripheral instances are updated in the _clock.c and the board_cfg.h file.
    Good to know, thanks
     
    > Having said that if you are looking for a third party
    > TI DEsign Network Resources
    Thanks, in case we can not solve within reasonable time we will invetigate it

    We will deep into the board folder a little more over the weekend but already now it build without errors but does not show up in the CSS GUI
    > you can go directly to Section 9 of the training application development with processor SDK RTOS
    Thanks, I will check it out
    Regards
  • Stefan Thorlacius said:
    The strange thing in both description is the line
    CFLAGS_GLOBAL_customAM572x  = -DSOC_AM572x -DevmAM572x
    Should not
    CFLAGS_GLOBAL_customAM572x
    be
    CFLAGS_GLOBAL_customBoard
    in line with the other text ?

    We also assume that the lines
    ifeq ($(BOARD),$(filter $(BOARD), myCustomBoard))
      PLATFORM_XDC = "evmAM572XCustom"
    endif
    Makes it visible in the CCS gui when creating new (RTOS, SYS/BIOS) project, that is, even if our board/package is using 'myCustomBoard' in file names and in makefiles it will be
    listed as 'evmAM572XCustom' in the GUI.

    I would recommend keeping this consistent with the custom Board name that you have picked. If you have used directory name "CustomBoard" use CFLAGS_GLOBAL_customBoard and name the XDC platform also as CustomBoard. Staying consistent will help locate all the files updated when you search in the PDK folder and ensure that you didn`t miss any updates to the makefiles.

    Stefan Thorlacius said:
    Here is another strange thing we can not sort out, already in the idk571x folder there is both the file idkAM571x_pinmux and the files
    generated from the PinMux tool (boardPadDelayDevice.c, boardPadDelay.h), is not the PinMux files used in the build ?
    We have assumed that we just dropp the PinMux files into the directory and they are "used" in the build.

     idkAM571x_pinmux project has been to import the baseline idkAM572x pinmux settings in the TI pinmux tool so you can modify that baseline rather than having to start from scratch. this is especially useful when your board is based of one of TI`s HW like in your case.  You can update the file after importing it and then just download and drop the files generated for PDK.  After you drop the updated files, you will need to rebuild the board for the changes to take effect.

    You can check the muxmode field in the PADCONFIG register for some of the key changes you made to verify the changes are applied. Dont forget the clocks and the peripheral instances specified in board_cfg.h  and _clock.c file to ensure the module is power up and enabled.

  • Stefan Thorlacius said:
    already now it build without errors but does not show up in the CSS GUI

    Good to know you are able to make progress here. Just to clarify the update to the .xdc or .bld files will not show up in CCS GUI but will be recognized by the XDC tools setting when you build a BIOS project.  For this to take effect you will need to update the BIOS configuration file as shown below:

    /* Load the Board package and set the board name */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

  •  

    Is it correctly assumed that the system design of the TI board "construction" is that, whatever peripherals we have?

    we add the init call of the LLD to Board init function in idkAM571x.c and then the initializing code of the LLD to

    idkAM571x_lld_init. (I know, it seems to be obvious but just to be sure)

    Let's say we want to add the LLD for USB/SPI/GPIO/mmcsd we do it similar as with the I2C?

     

    So the "trick" for customboard setup is to find Board_XXXXXConfig code to add to the idkAM571x_lld_init.c?

     

     

    Now, regarding for example the I2C (our board is named P2HMI)

    In Board_internalInitI2C in file pdk_am57xx_1_0_13/packages/ti/board/src/P2HMI/idkAM571x_lld_init.c there is a loop

        /* Board i2c usage does not depend on interrupts */

        for (i=0; i < I2C_HWIP_MAX_CNT; i++)

     

    The constant I2C_HWIP_MAX_CNT is defined in pdk_am57xx_1_0_13/packages/ti/drv/i2c/soc/I2C_soc.h

    This file does not have anything to do or have any knowledge about how many I2C we are using on our board.

    Is the idea behind the framework that every (I2C) "silicon stacks" are initialized but depending on how the pinmux setup those peripherals we are not using will just be ghosts?

     

     

    > be recognized by the XDC tools setting when you build a BIOS project. 

    > For this to take effect you will need to update the BIOS configuration file as shown below:

    > /* Load the Board package and set the board name */

    > var Board = xdc.loadPackage('ti.board');

    > Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

     

    Which file is this?

    We found 'Board.Settings.boardName' in a lot of files under ti/pdk_am57xx_1_0_13 but they

    are under either a test or example directory.

    'Board.Settings.boardName' is not find in any file in ti/bios_6_73_01_01

     

  • Stefan,

    I was able to prioritize the collateral to address this porting in the software developer guide which should now be available here:

    Stefan Thorlacius said:

    Is it correctly assumed that the system design of the TI board "construction" is that, whatever peripherals we have?

    we add the init call of the LLD to Board init function in idkAM571x.c and then the initializing code of the LLD to

    idkAM571x_lld_init. (I know, it seems to be obvious but just to be sure)

    Let's say we want to add the LLD for USB/SPI/GPIO/mmcsd we do it similar as with the I2C?

    No, the LLD init in board is limited to peripherals required to setup the SOC and key interfaces like I2C LLD for PMIC (power management) and Board ID detect, MDIO PHY for Networking and UART for debug logging. you can initialize other peripherals if you choose to but I would recommend that you keep other peripheral init in the application to allow for flexibility of modifying the LLD configuration  (DMA, interrupt, mode of operation, etc) without having to rebuild the board library. 

    No, if you see the code in the function it is calling I2C open only for the instance that is connected to the EEPROM. The I2C configuration however seems to be changed for all instances. In this case, the code doesn`t need to do it for all instance. It can limit the driver configuration change the BOARD_I2C_EEPROM_INSTANCE

    Stefan Thorlacius said:

    > be recognized by the XDC tools setting when you build a BIOS project. 

    > For this to take effect you will need to update the BIOS configuration file as shown below:

    > /* Load the Board package and set the board name */

    > var Board = xdc.loadPackage('ti.board');

    > Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

    If you look at any RTOS PDK example project. Each project contains a .cfg that indicates which BIOS and PDK module needs to be included and the configuration setting of each of these modules. For example: Look at the AM572x UART driver example configuration file located at pdk_am57xx_1_0_xx\packages\ti\drv\uart\example\sample\am57x\armv7\bios\uart_arm.cfg

    Check the setting that includes the board library using the script 

    /* Load the Board package and set the board name */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "idkAM572x";

    If you are not using RTOS then this comment doesn`t` apply to you. In case of bare-metal  code, you can simply link to the correct board library in your linker settings.  You don`t need to modify anything in the BIOS package. All of your board porting changes should be limited to PDK package. 

  • Hi

    (we base our board, P2HMI on idk571x, hence P2HMI in the following text)
    Our PCB will use external DDR3 ram, a number of SPI, I2C and UARTS, USB, SD/MMC, EMAC and and later PRUSS.
    It will be RTOS (SYS/BIOS) based software (which, when done with it's tests, start an uboot to get the linux going)

    Your recomendation is to remove the Board_getIDInfo and Board_writeIDInfo (beacouse we do not have the TI specific EEPROM) sound correct.

    The reason to keep Board_uartStdioInit in the board build is to make it possible for the examples and diagnostic application to output a result in case we want to make the SPI diagnostic test?

    This also means that we should keep Board_icssEthConfig if we want the examples and diagnostic applications to work ?

    ---

    When is the function Board_init supposed to be called ?

    In

    ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/test/src/main_uart_test.c

    it is expclicitly called but in

    /ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/example/UART_BasicExample_Intr_ExampleProject/src/uart_intr_test.c

    t is never called (if it is not called in Error_init or BIOS_start)

    or the line

    var System    = xdc.useModule('xdc.runtime.System');

    is calling it?

    Will the CCS compile the argument to function Board_init depending on what is declared in the .cfg file.

    ---

    I followed the new page you linked to

    and I think there might be an error, if we add the line

    CFLAGS_GLOBAL_P2HMI  = -DSOC_AM571x -DP2HMI=P2HMI

    (original text on page is CFLAGS_GLOBAL_myCustomBoard  = -DSOC_AM572x -DmyCustomBoard=myCustomBoard )

    and when making the board we get the followinfg error message

    > gmake board_lib LIMIT_SOCS=am571x LIMIT_BOARDS=P2HMI clean
    > gmake board_lib LIMIT_SOCS=am571x LIMIT_BOARDS=P2HMI
    gmake[5]: Entering directory `C:/ti/pdk_am57xx_1_0_13/packages/ti/board'
    # Compiling P2HMI:am571x:a15_0:release:board: src/board.c
    C:/ti/gcc-arm-none-eabi-6-2017-q1-update/bin/arm-none-eabi-gcc -MD -MF C:/ti/pdk_am57xx_1_0_13/packages/ti/binary/ti/board/board/obj/P2HMI/a15/release/.deps/board.P -DMAKEFILE_BUILD -Wimplicit -Wall -Wunused -Wunknown-pragmas -ffunction-sections -fdata-sections -c -mcpu=cortex-a15 -g -mfpu=neon -mfloat-abi=hard -mabi=aapcs -mapcs-frame -D__ARMv7 -Werror -O2 -s -DNDEBUG    -DP2HMI -DSOC_AM571x -DP2HMI=P2HMI -IC:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include -IC:/ti/gcc-arm-none-eabi-6-2017-q1-update/arm-none-eabi/include/newlib-nano -I. -Isrc -Isrc/P2HMI -Isrc/P2HMI/device -Isrc/P2HMI/include -IC:/ti/pdk_am57xx_1_0_13/packages/ti/drv/i2c/soc/am571x -IC:/ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/soc/am571x -IC:/ti/pdk_am57xx_1_0_13/packages/ti/drv/spi/soc/am571x -IC:/ti/pdk_am57xx_1_0_13/packages -IC:/ti/edma3_lld_2_12_05_30C/packages -IC:/ti/pdk_am57xx_1_0_13/packages/ti/csl -I/apps/apps_nonbam/inc -I/ -I/common   -o C:/ti/pdk_am57xx_1_0_13/packages/ti/binary/ti/board/board/obj/P2HMI/a15/release/board.oa15fg src/board.c
    <command-line>:0:0: error: "P2HMI" redefined [-Werror]
    <command-line>:0:0: note: this is the location of the previous definition
    cc1.exe: all warnings being treated as errors
    gmake[5]: *** [C:/ti/pdk_am57xx_1_0_13/packages/ti/binary/ti/board/board/obj/P2HMI/a15/release/board.oa15fg] Error 1

    --

    we guess the line

    CFLAGS_GLOBAL_P2HMI  = -DSOC_AM571x -DP2HMI=P2HMI

    should only be

    CFLAGS_GLOBAL_P2HMI  = -DSOC_AM571x

    but even if we change it and compile the board without any problems it still do not show up here

    We must be missing a step that make it vissible in the CCS GUI

    Regards

  • Stefan Thorlacius said:

    Your recomendation is to remove the Board_getIDInfo and Board_writeIDInfo (beacouse we do not have the TI specific EEPROM) sound correct.

    The reason to keep Board_uartStdioInit in the board build is to make it possible for the examples and diagnostic application to output a result in case we want to make the SPI diagnostic test?

    This also means that we should keep Board_icssEthConfig if we want the examples and diagnostic applications to work ?

    That is correct. To reuse the software that we provide for the IDK, you would need to remove the BOARD ID and EEPROM related code. Also since you are reusing the design for SPI and ICSS, you can keep that code in the board llbrary so you can call into the functions and run diagnostic based of the same code to checkout your design. 

    Stefan Thorlacius said:

    When is the function Board_init supposed to be called ?

    In

    1
    ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/test/src/main_uart_test.c

    it is expclicitly called but in

    1
    /ti/pdk_am57xx_1_0_13/packages/ti/drv/uart/example/UART_BasicExample_Intr_ExampleProject/src/uart_intr_test.c

    t is never called (if it is not called in Error_init or BIOS_start)

    or the line

    1
    var System    = xdc.useModule('xdc.runtime.System');

    is calling it?

    Will the CCS compile the argument to function Board_init depending on what is declared in the .cfg file.

    Board_init is an initialization call so is usually called right at the beginning of main in the application or in your bootloader code where SOC/system static initialization is required before exercising the cores and interfaces.

    Board_init call is an API call into the board library that you include using the .cfg file using the following syntax

    /* Load the Board package and set the board name */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "idkAM572x";

    You need to include the board.h header file for the compilation to pick up the macros that are passed to the Board_init. To link to the board library that you have created, you can change this to 

    Board.Settings.boardName = "P2HMI";  //Make sure this matches your board name.

    The platform that you are picking in the CCS in the screenshot is the BIOS platform definition which specifies the core that you are compiling for and the memory layout of the platform. This is not related to board and typically you can set this to evmAM572x.

    If you are interested in seeing how the memory is defined refer to the file Platform.xdc here:

    bios_6_7x_xx_xx\packages\ti\platforms\evmAM572X

    This only defines the cores in the SOC and memory map so typically doesn`t need to be modified. 


  • Hi
    There is something is fuzzy about this as well
    The board is compiled without errors and ends up here
    ti/pdk_am57xx_1_0_13/packages/ti/board/lib/P2HMI

    But when compiling the CCS Project, the build tools only look here
    'C:/ti/bios_6_73_01_01/packages;C:/ti/xdctools_3_51_01_18_core/packages;..;'. Ensure that the package path is set correctly.
    Why is not the tool looking among the board builds in ?
    ti/pdk_am57xx_1_0_13/packages/ti/board/lib/P2HMI
    should the board be included like this ?
    var Board = xdc.loadPackage('../../../pdk_am57xx_1_0_13/packages/ti/board/lib/');
    Board.Settings.boardName = "P2HMI";

    Should be board be post processed in some way with for example with XDCTOOL ?
    or just copied from ti/pdk_am57xx_1_0_13/packages/ti/board/lib/P2HMI ?
    indicated by C:/ti/xdctools_3_51_01_18_core/packages in
    'C:/ti/bios_6_73_01_01/packages;C:/ti/xdctools_3_51_01_18_core/packages;..;'. Ensure that the package path is set correctly.

    There is not even a board directory under
    C:/ti/xdctools_3_51_01_18_core/packages/ti
  • Stephen,

    The way the RTSC BIOS build works. The XDCtools looks for modules in the .cfg file in the package repositories that you have specified in your project. Can you check and confirm the XDC Settings of the project and confirm PDK\ packages is added there as shown below:

    Regards,

    Rahul

  • Hi

    My Project property looked like this

    It seems that the default setup of a Project in CCS is that it is not aware of anything beneath …./ti/...

    However when I try to add Another repostiry, the TI_PDK you suggested the CCS Environment is not aware of the PDK Environment variable you suggested

    But I added it manually (by typing it) like this

    But it did not find it anyway

    So it seems that it is neccessary to make CCS aware of TI_PDK_INSTALL_DIR (this is oddly, you could expect that the installation of PKG in the first place should have made TI_PDK_INSTALL_DIR aviable to CCS)

    Shall I reinstall the PDK package or manually add TI_PDK_INSTALL_DIR somewhere ?

  • Stefan,

    When you start with Processor SDK RTOS development, one of the first getting started steps is to discover processor SDK RTOS components  as described here:

    When you complete this process, you will see the PDK being added to CCS Products (Windows->Preferences-> Code Composer Studio-> Products)

    This allows user to add this product to their project when creating a  new project and defines the MAcro in the linked resources as you can see in screenshot below:

    Regards,

    Rahul

  • Hi

    Our setup is similar to yours for the first steps but not on the last

    The first screen shot is the same as yours but the next ones are not

    The second screen shots shows how it look when we try to create a SYS/BIOS Project for the AM571X platform ARM A for the 5718

    As you can see, it does not show our board (ti.platforms.evm5718 was chosen just to be able to finish the Project setup)

    The third screenshot is the properties for the newly created Project.

    Even if screenshot 1 shows that it "knows" about am57xx, the Environment variable show up in screenshoot 3)

    Are we supposed to add this "COM_TI_PDK_INSTALL_DIR" somewhere ?

    Did we make any misstakes when installing the PDK package, shall we re install it?

  • Additional information

    After pressing the "Rediscover…." button in the CCS preferences, recreating a Project based on the ti.evm571xx and then added your suggestion

    /* Load the Board package and set the board name */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

    The buildenvionment seems to found it, we could compile the Project without errors but we have not tested it yet, let us investigate it a Little more.

    I suggest that the follwoing is added to the "how to build custom board build description" you provided earlier

    • That the custom platform will not show up in the GUI, these are SYS/BIOS internal platforms

      If not, it will confude people that their board does not show up in the GUI


    • Accesing a custom board is done like this

    /* Load the Board package and set the board name */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

    • If the Project does not build, that is, compile/linkerror
      try to press the button "Rediscover" in the preferences to CCS Project.


    We will check into the newly build Project to see if Board_Init is accessable, brb

    Regards

  • Stefan Thorlacius said:

    After pressing the "Rediscover…." button in the CCS preferences, recreating a Project based on the ti.evm571xx and then added your suggestion

    /* Load the Board package and set the board name */
    var Board = xdc.loadPackage('ti.board');
    Board.Settings.boardName = "customBoard";  // Was previously "idkAM572x"

    The buildenvionment seems to found it, we could compile the Project without errors but we have not tested it yet, let us investigate it a Little more.

    Glad to know you are making progress. I suspected some issue with the setup as the variables get auto defined when the eclipse plugin for the PDK package is detected in CCS.

    Stefan Thorlacius said:

    I suggest that the follwoing is added to the "how to build custom board build description" you provided earlier

    • That the custom platform will not show up in the GUI, these are SYS/BIOS internal platforms

      If not, it will confude people that their board does not show up in the GUI

    Thanks for the suggestion. I will update the documentation to reflect this to avoid any confusion.