AM5728: No prints on minicom when SD card with rtos diagnostic test image in inserted

hi,

This is a gentle reminder. Please reply to my query

akshi malhotra said:

1) Our custom board is based on AM5728, We want to test LVDS interface in our custom board. Can we do a baremetal test for it?

yes, you can do. take a look at following example in our vision sdk (TDA2x) package  : vision_sdk\ti_components\drivers\pdk_xx_xx_xx_xx\packages\ti\drv\vps\examples\vip\captureVip\src example.

Many tests in this example use FVID2_VID_SENSOR_MULDES_OV1063X_DRV as driver id, which internally uses LVDS interface to receive data.

akshi malhotra said:

2) We are trying to run RTOS diagnostics tests on our custom board based on AM5728. Whne the create an SD card with the diagnostics applications and insert it in our board, we are not getting any prints on minicom. The UART interface is same as in SOC. We have dome changes related to pinmux and DDR also.

The serial port is working when we insert SD card with uboot. what changes are required to get prints on minicom(serial port)?

Since, you are able to see the prints, while booting with uboot, your UART lines are fine. You probably have to recheck your pinmux and DDR configuration. 

akshi malhotra said:

3) We tried running the diagnostics test from CCS, it is showing the test is running but no prints can be seen on minicom or CCS? Can we divert the diagnostic application prints to CCS?

You can do that by replacing all UART_printf with C programming printf. But it is not recommended.

akshi malhotra said:

4) How can we configure memory map for 4GB DDR?

You can change that below configuration according to your requirements:

packages\ti\board\src\<board_name>\include\board_cfg.h.

Hi Anubhav,

2)

We have replaced the following pinmux files with files generated by pinux tool in path pdk_am57xx_1_0_17/packages/ti/board/src/evmAM572x :  boardPadDelayDevice.c, boardPadDelay.h, boardPadDelayInit.c and boardPadDelayTune.h

We have not modified clock files : evmAM572x_clock.c and evmAM572x_pll.c as there are no changes in clock of our custom board.

We have modified the register values in file evmAM572x_ddr.c based on values generated by DDR emif tool.The following values were modified in evmAM572x_ddr.c :

Board_STATUS Board_DDR3Init()

{

………..

hCtrlCoreWkup->EMIF1_SDRAM_CONFIG_EXT = 0x0000C123U;

hCtrlCoreWkup->EMIF2_SDRAM_CONFIG_EXT = 0x0000C123U;

………….

ddr3Config1.emifDdrParam.sdramTim1 = 0xCAAAD4DBU;

ddr3Config1.emifDdrParam.sdramTim2 = 0x208F7FDAU;

ddr3Config1.emifDdrParam.sdramTim3 = 0x407F88B8U;

ddr3Config1.emifDdrParam.sdramCfg = 0x61851BB2U;

ddr3Config1.emifDdrParam.sdramCfg2 = 0x00000000U;

ddr3Config1.emifDdrParam.sdramRefCtrl = 0x00000C30U;

…………

if(BOARD_SOK == retVal)

{

……….

ddr3Config2.emifDdrParam.ddrPhyCtrl = hEmif2->regs->DDR_PHY_CONTROL_2;

ddr3Config2.emifDdrParam.sdramTim1 = 0xCAAAD4DBU;

ddr3Config2.emifDdrParam.sdramTim2 = 0x208F7FDAU;

ddr3Config2.emifDdrParam.sdramTim3 = 0x407F88B8U;

ddr3Config2.emifDdrParam.sdramCfg = 0x61851BB2U;

ddr3Config2.emifDdrParam.sdramCfg2 = 0x00000000U;

ddr3Config2.emifDdrParam.sdramRefCtrl = 0x00000C30U;

…………..

if(BOARD_SOK == retVal)

{

/* MA_LISA_MAP_i */

//CUSTOM BOARD CHANGES

hMampuLsm->MAP_0 = 0x00000000;

hMampuLsm->MAP_1 = 0x00000000;

hMampuLsm->MAP_2 = 0x80740300;

hMampuLsm->MAP_3 = 0xFF020100;

/* DMM_LISA_MAP_i */

hDmmCfg->LISA_MAP[0U] = 0x00000000;

hDmmCfg->LISA_MAP[1U] = 0x00000000;

hDmmCfg->LISA_MAP[2U] = 0x80740300;

hDmmCfg->LISA_MAP[3U] = 0xFF020100;

…………..

Uint32 sdRamRefCtrlInit = 0x000030D4U;

Uint32 sdRamRefCtrlInit = 0x000040F1U;

…………...

}

We have done changes in board_cfg.h for support of 4GB ram  as follows:

define BOARD_DDR31_START_ADDR 0x80000000

#define BOARD_DDR31_SIZE (2 * 1024 * 1024 * 1024UL)

#define BOARD_DDR31_END_ADDR (BOARD_DDR31_START_ADDR + BOARD_DDR31_SIZE - 1)

/* Mmeory Sections */

#define BOARD_DDR32_START_ADDR 0x200000000

#define BOARD_DDR32_SIZE (2 * 1024 * 1024 * 1024UL)

#define BOARD_DDR32_END_ADDR (BOARD_DDR32_START_ADDR + BOARD_DDR32_SIZE - 1)

3)

We tried replacing UART_printf with printf but we still cannot see any prints on CCS console

2)

Board_ddr.c file will come into play when you pass BOARD_INIT_DDR to Board_init(). What I suggest you to do is modify the gel file according to the output of emif tool and try connecting CCS. Once connected, either you run a helloworld program out of DDR or simply you can open the memory browser and confirm whether you are able to access DDR memory. In this way, you can confirm your ddr configuration and then you can move to modify board library.

3)

printf() should work, but as you told it is not working,  it may be a problem with heap and stack. Please check attached project. I have verify this on AM571x. I don't have AM572x setup with me as we are working remotely, but same should work there also. If you don't see any prints here also, then let me know, will try to find a AM572x setup.

Towers_of_Hanoi.zip

Hello Anubhav,

2) We have done changes in DDR_config gel file according to EMIF tool. We are able to access DDR memory through memory browser and once we load the hello world binary it is showing the loaded code in memory browser also. We were able to connect to our custom board through CCS, when we loaded the hello world binary we could not see the print "Hello world" on ccs console and on minicom terminal. But it's status is shown as running in CCS.

3) We built the project towers of hanoi for our board and loaded it, we are not able to see any prints on both CCS and minicom. The status of project is shown as running. 

We are using CCS in windows 10. In the memory MAP we are not able to see the entries for RAM address.

Below is the screenshot of memory browser:

Below is the screen shot of memory map:

akshi malhotra said:

But it's status is shown as running in CCS.

What exactly you mean by running? Are you running any test having visual output like LED blinking. If your board have LEDs, try to toggle that, It will verify that code is actually running and not breaking. Tower of Hanoi should work, try to align the memory configuration in tower_of_hanoi"s linker file to your board's configuration. Also, you can see the below FAQ on semihosting: https://e2e.ti.com/support/processors-group/processors/f/processors-forum/947316/faq-how-does-semihosting-work-with-ti-rtos-sys-bios-and-gcc?tisearch=e2e-sitesearch&keymatch=RTOS%2520printf%2520gcc

akshi malhotra said:

We are using CCS in windows 10. In the memory MAP we are not able to see the entries for RAM address.

The memory map what you see here is getting loaded from gel file. As mentioned in the heading of memory map, "Note that this page can only be used to view the memory map of the selected target. To modify the memory map, click on Gel Files and specify a Gel file with the desired memory map." Therefore, you need to modify the gel to align to your custom configuration. 

Hello Anubhav,

1) There is no LED present in our custom board, we tried running tests like memory test, temperature sensor, eMMc and PMIC test. But no prints are being displayed on both CCS console and minicom console.

2) As suggested by you, we tried running Tower of Hanoi application on our bare custom board, even though it shows that the test is running,  but no prints were being displayed on CCS console. 

The same application was tried on AM5728 Evaluation module, but no prints were being displayed on CCS console.

Step-wise debugging was also tried, it shows that the printf is being executed but no prints were displayed on console/debugger console. Can you provide us the MEMORY configuration for am572x?

2)The same tester software was also tried on EVM AM572x with SD card, it was working fine. But when we ran the same tester software on our custom board (bare board), no prints are visible in the minicom console.

3) When we port the u-boot and kernel, it is working fine on the custom board, we are able to work on u-boot and kernel prompt and corresponding prints are being displayed on minicom console. Also DDR RAM configuration shown is 4GB on running command < free -h >.

From the above trials,  I can infer that:

a) Hardware connection of the minicom is fine since we are able to see prints on minicom console at uboot and kernel stage.

b) DDR Memory configuration also seems fine as we are able to verify the 4GB configuration at kernel prompt.

Could please verify our PINMUX entries and GEL files because minicom prints are not being displayed on runningTester Software in either of the setup - CCS and SD Card. 

Also, the same tester software with new PNIMUX entries and GEL files of the custom board is running fine on Evaluation Module. 

Please note that there is no difference in PINMUX and register address of On-Chip peripherals - PMIC, temperature sensor, EEPROM etc between custom board and Evaluation Module.

2671.AM572x_ddr_config.gel

AM572x_pad_config.gel

BOARD LIBRARY FILES DIFF FOR AM572X AND CUSTOM BOARD

4101.diff.log 

Hi,

akshi malhotra said:

1) There is no LED present in our custom board, we tried running tests like memory test, temperature sensor, eMMc and PMIC test. But no prints are being displayed on both CCS console and minicom console.

Then, how you are confirming that it is running and not hanging/breaking in between.

akshi malhotra said:

The same application was tried on AM5728 Evaluation module, but no prints were being displayed on CCS console.

you can try inbuilt "Hello World" project from CCS, File ->new->ccs project->choose the board and example.

akshi malhotra said:

Can you provide us the MEMORY configuration for am572x?

Default configuration will be there with new project creation as mention earlier.

akshi malhotra said:

Hardware connection of the minicom is fine since we are able to see prints on minicom console at uboot and kernel stage.

Yeah, its pinmux and gel issue.

akshi malhotra said:

DDR Memory configuration also seems fine as we are able to verify the 4GB configuration at kernel prompt.

yeah but that is through linux, you have to cross checked the configuration ccs is picking and linux boot is picking are same or not. This will go for pinmux as well.

akshi malhotra said:

Also, the same tester software with new PNIMUX entries and GEL files of the custom board is running fine on Evaluation Module. 

Is the pinmuxing(for UART) on both the board is same? 

You can also probe UART lines from SOC side to see anything is happening or not when you issue UART_printf().

Meanwhile i will take a look at your files.

Hello Anubhav,

An update to our trials:

1) Tower of Hanoi application suggested by you is now working on AM5728 Evaluation module. However, it is still not working on our bare custom board

Regards

Akshi

ANUBHAV AKASH

akshi malhotra said:

Tower of Hanoi application suggested by you is now working on AM5728 Evaluation module. However, it is still not working on our bare custom board

nice to hear that. Basically, it is more of compiler and linker issue and  ccs console prints are related to compiler's semihosting option. As mentioned earlier, you can see this link for more details -  https://e2e.ti.com/support/processors-group/processors/f/processors-forum/947316/faq-how-does-semihosting-work-with-ti-rtos-sys-bios-and-gcc?tisearch=e2e-sitesearch&keymatch=RTOS%2520printf%2520gcc.

I went through your files, I found some pointers indeed:

•  2671.AM572x_ddr_config.gel - AM572x_DDR3_532MHz_Config(): If EMIF2 available, you are only reseting emif params, line 1025 is having only (SOC_EMIF2_CONF_REGS_BASE); you have to set after resetting it.
• 4101.diff.log - While doing UART3 rxd pinmuxing, value you are giving is 0x50002, can you try replacing it with 0x60002 and check.
• And also can you probe and check the UART lines from SOC side and try to see something there.

Hello Anubhav,

We did the suggested changes in gel files and have the following observations:

1) Running tester software through CCS:

When we run the tester software executables(.out) from CCS, the test is running and we can see the prints on minicom. However,  prints are being displayed on minicom only when the SD card with u-boot and kernel image is inserted in the board. If the SD Card is removed from the bare custom board, no prints are being displayed. How the prints of any tests depend on the SD Card even though the tests are running from emulator through CCS?

It seems that it is not a hardware issue as the prints are being displayed on minicom, however, dependency on SD Card is still not clear.

2) Running Tester Software through SD Card:

On running tester software through SD Card, the issue still persists that no prints are being displayed on minicom. In this case, MLO, app, framework utility is also loaded, still, the tester software menu is also not loaded.

3) As suggested by you, replaced UART_printf with printf (assuming prints shall be directed on CCS console instead of minicom), but no prints can be seen on CCS.

4) Also, modified the value of UART3 rxd pinmuxing to 0x60002, still no prints can be seen in cases 1 & 2.

Regards

Akshi

Hi,

akshi malhotra said:

1) Running tester software through CCS:

• If possible, can you share your source code/project. 
• you are using SD boot for initialization?

akshi malhotra said:

How the prints of any tests depend on the SD Card even though the tests are running from emulator through CCS?

It will not depend. What happening in your case is uboot is doing the pinmuxing/initialazation for you, therefore you are seeing prints after that.

• compare the pinmuxing done by linux with your baremetal.

akshi malhotra said:

2) Running Tester Software through SD Card:

• can you share your SD card contents as well.

akshi malhotra said:

3) As suggested by you, replaced UART_printf with printf (assuming prints shall be directed on CCS console instead of minicom), but no prints can be seen on CCS.

As mentioned earlier, it is a configuration part. You can go through links that are already shared or the below link: https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_how_to_guides.html#semihosting

akshi malhotra said:

4) Also, modified the value of UART3 rxd pinmuxing to 0x60002, still no prints can be seen in cases 1 & 2.

What you are facing is a PINMUXING issue only. One more debug technique is pinmux these lines to GPIO (in board library) and toggle it high and low from application. Probe and see toggling is happening or not. This will confirm whether we are checking the right pinmux or not. 

Hello Anubhav,

No changes have been done in the diagnostic applications source code present at

packages/ti/board/diag. However, changes are made in pinmux and board configuration present in packages/ti/board/src/evmAM572x/

1) Please find the attached source code files below:

evmAM572x.tar 

2) Please find attached the sdcard contents below:-

sdcard.tar

3) Please elaborate what does SD Boot initialization means?

When running tester software through JTAG emulator, without SD Card, no prints are being displayed and on SD Card connection prints are being displayed on minicom console.

Yes, when running tester software through SD Card, booting is done through SD Card only.

Regards

Akshi

Hi,

I think I get the issue here. Can you provide/confirm the below things.

• can you specify which .out, you loading from CCS. You can load any *.out from CCS. Try loading any other .out.

akshi malhotra said:

No changes have been done in the diagnostic applications source code present at

packages/ti/board/diag

 make sure that particular diagnostic have BOARD_INIT_PINMUX_CONFIG along with BOARD_INIT_UART_STDIO while doing Board_init(). By default you will see only BOARD_INIT_UART_STDIO.

akshi malhotra said:

Please elaborate what does SD Boot initialization means?

While booting from SD card, BOARD_INIT_PINMUX_CONFIG is taken care as part of sbl/MLO. We prefer our customer to boot from SD, thats why we enable only BOARD_INIT_UART_STDIO by default.

Hi,

1. After enabling BOARD_INIT_PINMUX_CONFIG flag in each diagnostic application, prints are being displayed now on minicom console. This issue is resolved when running tester software through CSS using JTAG emulator.

2. However, when running the tester software through SD Card, prints are still not coming on minicom console.

As per our understanding, on compiling tester software for SD Card, .out generated are converted to binaries - PMIC_Test, EEPROM_Test, EMMC_Test, etc. Since, .out  files are running fine through CCS, it seems that diagnostic applications are correct.  But, MLO, app and framework binaries are coming into picture when running tester software through SD Card. Please verify.

Regards

Akshi

akshi malhotra said:

1. After enabling BOARD_INIT_PINMUX_CONFIG flag in each diagnostic application, prints are being displayed now on minicom console. This issue is resolved when running tester software through CSS using JTAG emulator.

Great to hear that.

akshi malhotra said:

However, when running the tester software through SD Card, prints are still not coming on minicom console.

You can test your MLO, by putting following files in SD card - MLO and app(rename any one of the running test(*_TEST) to app).

Basically, after running MLO it will look for "app". So, MLO and app are the minimal files needed to boot from SD.

Hi Anubhav,

As suggested by you, I tried renaming PMIC_TEST to app.

1. First, it  was tried on EVM, on running tester software through SD Card, automatically PMIC test ran. Hence, trials was  successfull.

2. However, when the same thing was tried on custom board, no prints are being displayed on minicom console.

As I told earlier, source code of the diagnostic application is not changed and running perfectly fine through CCS using JTAG emulator.

It seems, something is not right in MLO as we have eliminated app and framework binary as suggested by you, by renaming one TEST to app.

Please guide !!

Regards

Akshi

Hi,

please focus on following pointers for now:

• forget about the framework for now. Focus on any one simple test - my suggestion would be a main() containing only board_init() and a UART_printf(). PFA for sample code, replace it with original file and build it again.
• Then, first check with CCS, if prints are coming or not on both the boards.
• If prints are coming with CCS, then put only MLO and app(PMIC_TEST renamed as app) and check on both the boards.
• If prints are coming on EVM but not on your custom board, then it is the issue with the MLO. I guess you are using same MLO for both the boards. If so, that will not work, you have to build MLO again for MMCSD and have to use that for your custom board.
  0636.pmic_test.c

  #include <stdio.h>
  #include <stdlib.h>
  #include <string.h>
  
  #include <ti/drv/i2c/I2C.h>
  #include <ti/drv/i2c/soc/I2C_soc.h>
  #include <ti/drv/uart/UART_stdio.h>
  
  #include "board.h"
  #include "board_cfg.h"
  
  /*
   *  ======== main ========
   */
  int main(void)
  {
      Board_initCfg boardCfg;
  
      boardCfg = BOARD_INIT_PINMUX_CONFIG |BOARD_INIT_UART_STDIO;
      Board_init(boardCfg);
  
      while(1)
      {
          UART_printf("\nTesting Console prints\n");
      }
  	return pmic_test();
  }
  
  

Hello Anubhav,

Please find the following observation below:

1. Given above code was replaced with pmic_Test and renamed as app.

2. While running the same through CCS using JTAG emulator, infinite prints of  "Testing Console prints" are coming.

3. But, running the same through SD-Card, no prints are being displayed.

4.When same MLO and app binary run on EVM,prints are coming on EVM.

As you pointed out, we are using same MLO for EVM and custom board both. We are not sure, what changes need to be done according to our custom board. We made changes in few files related to pinmux in the directory packages/ti/board/src/evmAM572 . No other changes are made apart from this for custom board.

Regards

Akshi

Hi,

Have you try building the sbl. While building sbl it will take account of board library changes or else you can manually build the board library first and then sbl. Once build, try with newly build MLO.

Hello Anubhav,

Following steps were done while compiling MLO

1. No changes are done in this directory : packages/ti/boot/sbl/

2. Few changes are done related to pinmux in the directory:  packages/ti/board/src/evmAM572x/ . Following files were changed:

boardPadDelayDevice.c
boardPadDelayTune.h
boardPadDelayInit.c
evmAM572x_ddr.c
include/board_cfg.h
boardPadDelay.h

All the changes in these files were made using TI PINMUX tool.  Please find the attached diff and the changed files.

3.  Compiled MLO and diagnostic applications.

customfile.tar

src.diff

Please guide if any changes are required in sbl directory for custom board.

Regards

Akshi

akshi malhotra said:

Please guide if any changes are required in sbl directory for custom board.

You can refer below documentation for SBL details on AM57xx platform: https://software-dl.ti.com/processor-sdk-rtos/esd/docs/06_03_00_106/rtos/index_Foundational_Components.html#am57x

akshi malhotra said:

Compiled MLO and diagnostic applications.

can you share your MLO and app for custom board as well as TIevm.

akshi malhotra said:

No changes are done in this directory : packages/ti/boot/sbl/

As mention in the documentation, some changes may required like initialization sequence, AVS,ABB setup. what you can do is follow the documentation, run and confirm the sbl example first.

Also can you mention which the command/process/sequence , you use to build the SBL and get MLO for your board.

files.tar

Hello Anubhav,

1. Please find the attached files - MLO for custom board and EVM, app and PMIC_TEST.

2. Also can you mention which the command/process/sequence , you use to build the SBL and get MLO for your board.

- cd rtos_folder/processor_sdk_rtos_am57xx_6_03_00_106/ 

- source setupenv.sh

- make

3.As per the documentation, it suggests Board_Init() initialize the UART through a flag BOARD_INIT_UART_STDIO, which is already happening in our source code.

Regards

Akshi

Hi,

akshi malhotra said:

As per the documentation, it suggests Board_Init() initialize the UART through a flag BOARD_INIT_UART_STDIO, which is already happening in our source code.

yeah, that is happening in your source code, but to load your app SBL/MLO is needed. And for MLO to work properly board_library(DDR, PLL/clocks, etc.) need to be aligned. What you can do is check in CCS after SD boot to find out where exactly it is getting stuck.