• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 103 subscribers
  • Views 1151 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

Speeding up the serial SPI Boot Load on a C5515/5505 DSP - preferred method ?

citizen
Expert 2840 points
Other Parts Discussed in Thread: TMS320C5515, TMS320VC5506

Hi,

I know that some-time ago there was a discussion on speeding up serial boot-loading from a 24-bit EEPROM, however there was no other follow-up on weather suggestions worked or not. Basically it would appear there could be two options in speeding up serial boot loading, either by :

1) Using -reg_config via Hex55to reconfigure the DSP PLL from its default 12MHz to say 98MHz or similarly higher value, however this appears to be explicitly disencouraged in the TI documentation data sheet for the TMS320C5515 such as : Note: The on-chip Bootloader allows for DSP registers to be configured during the boot process. However, this feature must not be used to change the output frequency of the system clock generator during the boot process.

2) Using -reg_config via Hex55to reconfigure the SPI module SPI_CLK frequency which by default is set to 500 KHz when booting from SPI EEPROM/Flash. For a 12MHz crystal that amounts to a SPI clock divider of 24 by default to get to 500KHz. Changing this to generate a division of say, 4 would increase the SPI_CLK frequency to 3MHz, however the possibility of doing this on the fly whilst the SPI module has already commenced booting off the EEPROM with a 500KHz clock is not documented in any TI documentation I was able to find. I may try this anyway, but would prefer a more reliable source.

Given there is a general requirement to increase boot-loading time of most 5000 series DSPs, what is the recommended / preferred method of doing this ? Any experience with any of the above methods, and /or stability issues once going to production for instance ? The later is important as there is the above Note in the TI documentation that explicitly recommends several times against changing the system clock on the fly during boot process (perhaps due to reliability / stability of boot process ?? this is not indicated why.)

If so, what other means exist there to achieve an overall speed-up of the firmware on boot ? Re-writing the boot-loader would not be an option for the moment ...

Many thanks in advance for any suggestions/experiences with above...

Regards, M

  • 0
    Genius 4630 points

    First of all, I don't think you can rewrite the bootloader since it is in ROM.  I am not aware of any method to override the internal ROM and substitute another.

    As to your question, you should try (2).  It should certainly work.

    Personally, I am working with a TMS320VC5506, and I did both (1) and (2), despite the warnings against (1).  I suspect that I will have to test this thoroughly before releasing it in the product.  If I have any problems, then I will discontinue (1) and just use (2) alone.  At the very least, initial testing on my custom board show that it works with a 24-bit ATMEL Flash chip.

    3) The C5506 has a Sample Rate Generator, SRGR register.  I set them to SRGR1_0:FWID=1 CLKGDV=2, since the maximum speed is with CLKGDV=2 (1 doesn't work).  Your C5515 registers may be different.

  • 0 in reply to Brian Willoughby
    Expert 2840 points

    Brian Willoughby said:

    First of all, I don't think you can rewrite the bootloader since it is in ROM.  I am not aware of any method to override the internal ROM and substitute another.

    Hi Brian,
    Thanks for the feedback. We did at some point consider loading a customised bootloader that then loads the actual firmware, but this is not our first preference as we'll loose the other benefits of the existing ROM bootloader.
    With regards to the (1) & (2), yes I would prefer to use (2) as it I have some doubt on the reliability of changing the system clock on the fly (besides it is discouraged in the documentation for a good reason perhaps ?!?). Anyway I will try both, with my preference for (2) first, and if that works then I'll leave it at that. Yes the SPI module for the 5505/15s are also simple to configure, with changing the CLKDV division register from its default value to obtain a faster clock. Only thing is that division by less than x4 is NOT recommended as it becomes unreliable, so the most I can do is divide the 12MHz clock by x4 to get a 3MHz SPI_CLK.
    The issue I have with method (1) is the fact it is discouraged in the doco, presumably for reliability reasons. On a mass scale if 95% of products boot without problems then that is great, but if the 5% do have problems then it is NOT ok, so my thoughts are more to do with what is a 100% reliable and consistent way to speed up boot time ? There is no word from TI how to do this reliably even though I suspect it is becoming a feature more and more required as application codes become larger. Testing could prove to be OK for a few modules in the lab, but statistically at production there could be some unwanted surprises unless we have a sure way to speed-up boot time.
    You did mention you tried (1) & (2), but are you using both at this time, or have you opted just for (2) as a permanent solution ? If this was the case, why did you opt out of using (1) ?? Did you experience some unreliable boots, or simply because it was discouraged in the documentation (I presume a similar note of caution is also made for the 5506 devices) ?
    What SPI clock frequencies are you getting now given the new speed settings ? We never did a test on maximum SPI transfer rates/clocks possible, but in essence the memory we are using is rated > 85MHz clock (even though this we would never need to use).
    Regards, M
  • 0 in reply to citizen
    Genius 4630 points

    Yes, the C5506 has similar cautions against changing certain settings, but upon closer inspection of the documents it seems that they are reverse of your chip.

    The C5506 bootloader warns against changing any register related to McBSP0, which implements the SPI interface.

    There are no cautions against changing the system clock generator.  In fact, a 'delay' opcode is available to allow the clock generator to settle on a new frequency before the bootloader continues.  In that respect, your (1) is the best single approach for a C5506.

    I mentioned (2) and (3), but they may only appear unique because of the SPI peripheral differences between the C5506 and C5515.  Technically, I am in violation of the bootloader recommendations by changing the CLKGDV register to 2.

    To answer your questions, I have never had a failure, and I have always tested with both (1) and (2) active.  However, my tests are incomplete because my firmware is still in progress.  In other words, I have erased the Flash and now exclusively use the Emulator to load my firmware.  Until I finish the firmware and have a demo ready for my client, there isn't much point to verifying that the aggressive solution works.  I merely went through the early tests to confirm that my hardware designs for the custom C5506 board were not going to surprise me later due to some unnoticed hardware mistake.  On a whim, I decided to try the most aggressively fast bootloader speeds, and when it was functional I decided that my hardware design did not need a revision.  As to whether I will retain the aggressive settings, that remains to be seen.

    If I were you, I would double-check the bootloader specifications for the C5515 and implement both versions of speedups.  Compare the default speed to the speedups that are non contraindicated, and then also compare the combination of (1) and (2).  You may find that the middle speed is fast enough compared to the default speed that you don't need to risk the maximum speed.  Then again, you may find that the maximum speed is perfectly reliable.  I have no idea whether your C5515 bootloader supports the delay option, but that may increase the reliability since it allows the clock generator to settle after a change.  I am not using the delay, but it's nice to have as an option.  You bootloader may be much simpler, though.

  • 0
    TI__Expert 8065 points

    Marin,

    A couple of tips for you.

    1) Regardless of the boot speed, the bootloader code won't jump to the customer code before 200msec elapsed. In other words, the boot load time is minimum 200msec.

    2) Please do not appemt changing PLL configuration for bootloader. The bootloader assumes a certain system clock frequency and set internal timer. So, the #1 should not be tried.

    If your boot time is much longer than 200msec and you want to reduce the boot time, I think #2 is the one you can try with your own risk. From the DSP standpoint, I don't see a problem, but I do not know how your SPI EEPROM will respond to "changing serial clock frequency on the fly".

     

    Good luck,

    Peter Chung

     

     

  • 0 in reply to Peter Chung
    Prodigy 10 points

    Peter,

    Can you provide power consumption figures for the boot sequence duration ?

    Thanks,

    Efraim.

  • 0 in reply to Peter Chung
    Prodigy 20 points
    Hi Peter,

    If you don't mind I continue in this old topic. Solution #2 from the first post (speeding up the SPI by changing CLKDV register) seems to work like a charm on a single device, but as M mentioned above, I need to be sure that this works reliable under all conditions before I can use this in production.

    Opposed to you, I do not worry about the SPI EEPROM having any problem with "changing clock frequency on the fly" since SPI is completely edge driven and therefore allowance of fluctuating clock speed is inherent to the SPI protocol.
    However, that does not guarantee that there aren't any pitfalls in the DSP itself regarding to changing the clock divider during usage of the SPI module. Is there any change that TI can evaluate this and confirm that this method is valid and will work under any condition, from the DSP standpoint?
  • 0 in reply to Henk de Vries
    Intellectual 875 points

    Solution 2 worked for me also.  I am using a C5515 loading from a 16MB SPI Flash device.

    I took the hex55 command line from the CCS makefile and modified it.

    Was: hex55.exe -boot -b -v5505 -serial8 "app.out" -o "app.bin"

    Is: hex55.exe -boot -b -v5505 -serial8 -reg_config 0x3000,0x0003 "app.out" -o "app.bin"

    Is there a way to modify the hex55 command line within CCS.  Currently the process is:

    1. Build the "app.out" file from CCS.
    2. Open a command line window and run the new hex55 command line to generate the "app.bin" file.

    Robert

  • 0 in reply to Robert Applebee
    TI__Genius 12575 points

    Hi,

      You can try adding the command in the ' post build steps using" CCS.

      Attached image as the details. Hope this works.

     

    Regards

     Vasanth