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.

TMS320F280049: serial flash programming through F28004x flash kernel

Part Number: TMS320F280049

While using the serial flash programmer I encountered a problem loading the kernel file onto the ram. After two hex digits the download on the HW stops as seen in the picture. Does anyone know what to do about it ? 

  • Hi Patrick,

    Windows sometimes appends some characters to the top of txt files when you open them in a text editor. Did you happen to do this?

    Can you try freshly building the .txt and merely copy and paste it to the place you need it? or better yet, just point to the build directory from the command line?

    If that does not solve it, then I think you will need to load the SCI bootloader symbols from the boot ROM to debug further.

    You also may be able use a slower baud rate and see if that helps.

    sal
  • Hi Sal,

    thanks for your reply, unfortunately after I resolved the issue with the kernel file I encountered another Problem.

    I followed your instructions and recompiled the kernel file. I am now able to download the kernel file onto the ram. Now I tried to load an application file onto the devices flash with the use of option 1-DFU. The application returns a NACK Error (see picture below). Is there someting that I did wrong ? I already lowered the baud rate but that didnt help.

    Best regards,

    Patrick

    German Aerospace Center

  • Hi Patrick,

    Please make sure the kernel is compiled using the proper GPIOs. There should be a parameter for this to a function call. It is either SCI_BOOT or SCI_BOOT_ALTERNATE.

    Are you using the proper GPIOs in the kernel? the same you are using in the bootloader?

    sal
  • Hi Sal,

    we are using the standars sci pin configuration GPIO28, and 29.

    I assume you meant this section in the code. I already compiled the kernel file in that configuration.

    Does it make a difference if i set the linker kommand to CPU1_RAM ?

  • The kernel should be loaded to RAM. I think the default build configuration should do that, but please make sure that is is linked and loaded to RAM.

    After loading the kernel, do you see the contents in RAM?

    sal
  • The default build option was set to BANK0_LDFU. I then set it to CPU1_RAM but there was no improvement.

    I came across the linker command file : 28004x_generic_ram_lnk.cmd am I right that this command file is valid for all variants of the C2000 F28004xo processors. Since we use the TMS320F280049C.

    I yet did not find out how to monitor the devices ram. I was only able to access the devices registers

    Patrick
  • That linker command file should be fine.

    Can you load the kernel using CCS, and use the Visual Studio project for the serial flash programmer and comment out the DownloadKernel() function? Then you can run the kernel and the serial flash programmer which would be sending the flash application. This will help to debug.

    Also, please search the E2E forum. There should be some other threads that would help you in this.

    Let me know what happens when you debug when loading the kernel via CCS.

    Regards,
    sal
  • Hey Sal,

    I followed your instructions and compiled the kernel with the RAM linker command file. It appears as if the kernel boots up but the application is stuck in autobaud.

    Secondly I tried to load the kernel via CSS and Jtag and recompiled the sfp with the kernel option opted out but the application still stopped at the autobaud. I once again looked at the SCI pin configuration of the kernel and HW but that does seem to be correct. Does it make a difference if I set the device from (default) f280049 to f280049C since I’m using that type of MC?

    Do you have an advice on how to continue ?

    I browsed the e2e and found some related threads but that didn’t quite solve my problem
  • If it cannot get past the autobaud lock, that makes me think there is something wrong with the connection to the pins that the SCI is using.

    Which pins are you using? How are you connecting to them?

    Also, which board are you using? controlCARD?

    Regards,

    sal

  • Hi Sal,

    we managed to resolve the issue. We use the processor on a custom board as a motor controller.
    There was something wrong with the oscillator settings in the kernel file since we use the internal oscillator.

    Best Regards and thank you for your help !
    Patrick
  • Glad you got it figured out.

    sal