• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 83 subscribers
  • Views 226 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

TMS320F28386S: Emulating SCI_Boot

John Hite
Expert 1355 points
Part Number: TMS320F28386S
Other Parts Discussed in Thread: HALCOGEN

It was necessary for me to emulate SCI_Boot as our hardware was not configured properly and the board will not be respun.

I got my pseudo SCI_boot to run and it accepted 23300+ bytes from the serial flash programmer. The initial destination is 0 and it correctly builds up from there. However, I am not sure it is safe to write to this starting location but I cannot tell for sure from the linker cmd file. Also if I interpret correctly the stack is at RAMM0_1 so that is being overwritten.

So I see 3 alternatives:

1) Adjust the linker command file so that 24K of spaces is skipped which seems would take up memory into GS1. Which may not leave enough for the app. A memory allocation map for our regular app is below.

2) Modify my pseudo SCI boot program to use an offset to load to our external RAM at 0x80000000, 16Mx16, IS45S16160J-7TLA2. I am not sure about the the first 2 blocks as the first one is destined for address 0 and the next for 0x1B4 which is in RAMM0 which starts at 0x1B1Hey

3) Knuckle down and figure out how to put the flash kernel into flash permanently. If I do so, to run it  from our main app would I load a function pointer with that flash address? Would the stack and any other addresses need to be changed?

My choice is number three as there seems to be plenty of flash available. But the repo flash_kernel_c28x_dual_ex1_c28x1 is naturally RAM based and I am having problems converting it to flash based. I would appreciate your observations and advise.

This is our current linker file:

Fullscreen
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#if 1
MEMORY
{
·· BOOT_RSVD······· : origin = 0x000002, length = 0x0001AE···· /* Part of M0, BOOT rom will use this for stack */
·· RAMM0_1········· : origin = 0x0001B0, length = 0x000648
·· // RAMM1_RSVD······ : origin = 0x0007F8, length = 0x000008········ /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
·· CLA_MSGRAMLOW··· : origin = 0x001480, length = 0x000080
·· CLA_MSGRAMHIGH·· : origin = 0x001500, length = 0x000080
·· RAMD0_1········· : origin = 0x00C000, length = 0x001000
·· RAMLS0·········· : origin = 0x008000, length = 0x000800
·· RAMLS1_5········ : origin = 0x008800, length = 0x002800
·· RAMLS6·········· : origin = 0x00B000, length = 0x000800
·· RAMLS7·········· : origin = 0x00B800, length = 0x000800
·· RAMGS0_1········ : origin = 0x00D000, length = 0x002000
·· RAMGS2_4········ : origin = 0x00F000, length = 0x003000
·· RAMGS5_6········ : origin = 0x012000, length = 0x002000
·· RAMGS7·········· : origin = 0x014000, length = 0x001000
·· RAMGS8_9········ : origin = 0x015000, length = 0x002000
·· RAMGS10_15······ : origin = 0x017000, length = 0x005FF8
·· // RAMGS15_RSVD···· : origin = 0x01CFF8, length = 0x000008········ /* Reserve and do not use for code as per the errata advisory "Memory: Prefetching Beyond Valid Memory" */
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Here is the current memory allocation.

  • 0
    TI__Genius 11405 points

    Hi John,

    Is the listed starting location 0 as in start of memory 0? Here are some considerations on the alternative options:

    1) Adjusting the linker cmd file by 24k would could be feesable if you were to move the sections for the rest of RAM memory to beyond 24k. I would check into the amount of RAM available on the device. When your application is running it will be from RAM correct?

    2) If the offset is used to load to external RAM, by first two blocks do you mean that it will always program at address 0 and 0x1B1 despite branching?

    3) The flash kernel can be placed in flash as EEPROM. An example is included in HALCoGen tool (http://www.ti.com/tool/HALCOGEN) for the device “TMS570LS31x_21x” (\ti\Hercules\HALCoGen\v04.07.01\examples\TMS570LS31x_21x\example_TI_Fee_Write_Read). Note: Instead of using F021 Flash API 2.0 (Hercules API), you have to instead use F2838 flash API (https://www.ti.com/lit/ug/spnu632/spnu632.pdf) – but the concept is similar.  Hercules devices core is ARM (byte-addressable) and C28x memory is 16-bit addressable. I've included the user guide below as pdf.

    2541.TI_FEE_User_Guide.pdf

    Thanks,

    Charles

  • 0 in reply to Charles Roberson
    Expert 1355 points

    Thanks for posting Charles.

    1) Looks like it has 44KB of RAM.

    2) My question is do the first two blocks need to go to their original address? The first block size is 2 and its destination is 0. The contents:

    0x0041    0x0044

    I don't know what it is but it may be significant since the next block does not write until address 0x1B4, which I thought might be the stack area. I know address 0002 is reserved but have not found anything definitive for 0000.

    So do these two blocks need to stay put or can they be moved also?

    3) This option looks ideal but I am supposed to have something working tomorrow and this looks like a tall hill to climb. So I probably need a Hail Mary rather than an ideal solution.

  • 0 in reply to John Hite
    Expert 1355 points

    I have been beating my head against a rock instead of thinking. There is an easier way to do this.

    I modified flash_kernel_c28x_dual_ex1_c28x1 to use my SCIA pins and built it as a standalone RAM app.

    Then I modified the serial flash programmer to skip the kernel download which was supposed to load flash_kernel_c28x_dual_ex1_c28x1.

    So far I have loaded a CPU1 app. I reset my board and the new code started printing its telltale message to SCIB.