• State
  • Locked Locked
  • Replies 2 replies
  • Subscribers 82 subscribers
  • Views 497 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.

TMS320F28035 serial flash programming issue

Corentin Zill2
Prodigy 20 points
Other Parts Discussed in Thread: TMS320F28035

Hi everybody,

I'm using the command line interface of Codeskin to program my TMS320F28035 through the serial port.

Sometimes programming works, sometimes not. After a few investigations, I discovered that the inaccurate baudrate from the uninitialized DSP is the problem. I started with a baudrate of 115200 baud and went down to 9600 baud, with random results. The cold spray and hot air gun also influence the behaviour.

The serial frames are echoed back during programming. The frames coming from my PC match the specified baudrate (let's say +/-0.5%). But the frames coming back from the DSP look to be far less accurate, with errors up to +/-3% on the baudrate. This causes the serial port of the PC - and of course Codeskin! - to not interpret the feedback of the DSP correctly.

As far as I know, the internal oscillator calibration should be performed automatically:
"The Device_cal() routine is programmed into TI reserved memory by the factory. The boot ROM automatically calls the Device_cal() routine to calibrate the internal oscillators and ADC with device specific calibration data. During normal operation, this process occurs automatically and no action is required by the user." (SPRUGL8C)
It this effective with the serial loader? Apparently no! This suggests me that a reliable serial flash programming is not possible without external oscillator! Am I right?

Otherwise, any suggestion on how to load my DSP with the serial port?

I tried different serial ports on the PC side. Some do accept +/-3% error on the baudrate (for example USB-to-serial converters), others don't. But this is not a real solution from my point of view.

Many thanks for your help,

Corentin

PS: I'm using the last version of Codeskin (v1.7), Win 7 64 bits, TMS320F28035PNS, SCI on GPIO28/29, internal oscillator.

  • 0
    TI__Guru* 81560 points
    Corentin,
    The Boot ROM calibration will trim the internal 0 pin oscillator to 10MHz assuming the temperature is 30C(room temp). As you have noted temp variation will cause the oscillator to move. Not sure if you are changing temperature during the load, but out of the box I am surprised that the oscillator accuracy(assuming you are at room temp) is not OK.

    At any rate, there is a secondary function called osc comp(an example is in CS) that will retrim based on the temp sensor feedback to compensate for this movement. You should be able to get 1% tolerance to 10MHz at a given temp if you call this function.

    Finally, I want to make sure you are using the internal VREG; there is also some frequency movement with VDD but using the on chip VREG practically removes this from the equation. If you are supplying your own VDD, this will make the above error statements incorrect to some degree.

    The 3% tolerance number for UART is for the system, so you have to factor in the other error sources in the system. I have gotten good results with the 28069 control stick that has UART thru the FTDI to USB on the stick up to 115.2k at room temp.

    If the above doesn't help, you can measure the output clock after boot cal and let me know if it is not agreeing with the above.

    Matt
  • 0 in reply to MatthewPate
    Prodigy 20 points

    Hi Matt,

    Thanks for your reply.

    I'm using the on-chip VREG, i.e. /VREGENZ tied low and no supply through the VDD pins. The power supply on the VDDIO pins is 3V3, regulated.

    In my case, TDO is shorted to GND when starting in order to enable the serial bootloader. Is the trimming of the internal oscillator already effective in this case?

    MatthewPate said:
    you can measure the output clock after boot cal

    Do you mean measuring XCLKOUT? Since XCLKOUT must be enabled by software, I probably cannot measure it when only the serial bootloader is active, right?

    Thanks!

    Best regards,

    Corentin