Reply by Jeff Brower January 4, 20072007-01-04
Denis-

Thanks a lot for posting that. I remember that "a few initial clock pulses" were needed to get the McBSP state machine going if you wanted the first word to be correct (i.e. not something like an ADC or other
continuous transmit). I guess that applies to bootloading also.

-Jeff
z...@mail.ru wrote:

> > Hi
> >
> >We have solved the problem. The serial clock has to run before the first
> >frame sync pulse. We added three clock cycles before the fram sync
> >pulse.
> >
> >
> > wrote:
> >original article: http://www.egroups.com/group/c54x/?startr
> >> Hi
> >>
> >> We have problems bootloading the DSP via the McBsp0 serial port.
> >> First we had a fault in the Hex file generated by the Hex500 ( Hex
> >> conversion
> >> utility program ). We had forgotten to specify the DSP version ( -v548
> >> ) for
> >> the Compiler. The entry point ( program start adress ) was also wrong
> >> in the
> >> Hex500 command file.
> >> Texas send us the assembly file of the bootloader program inside the
> >> 5402
> >> DSP.We looked through this code and found that the hex file with the
> >> code
> >> to be loaded to the DSP seems correct.
> >> The McBsp0 port uses a 16 bit boot mode, and the BFSR0, BCKLR0 and
> >BDR0
> >> are
> >> controlled from an external master. The DSP gives a low level on the
> >> XF pin
> >> when it is ready to be bootloaded.
> >> A receive interrupt starts the serial boot mode. Thus, the first word
> >> send
> >> to the DSP starts the McBsp0 bootloading. The first word also has to
> >be
> >> equal
> >> to 10AAh, or else the bootloader program exits the serial boot mode.
> >> We use a Fujitsu microcontroller to bootload the DSP. We are certain
> >> that
> >> the hex file is correct and that the connections on the serial port
> >are
> >> correct.
> >> The MP/!MC pin is low during reset, and this should start the
> >bootloader
> >> program, as we also are able to measure on the XF pin.
> >> We are not sure if the timing of the signals are correct.
> >>
> >>
> >> Are the assumptions below correct ?
> >>
> >> The signals does not look as ideal as the signals shown in the Texas
> >> documentation. I cannot see that this should be a problem since this
> >is
> >> a
> >> synchronous communication where the transfer is controlled by the
> >> serial clock.
> >> The frequency of our clock is not constant. We send 16 clock pulses,
> >> one for
> >> each bit. The bits are clocked out on the rising edge of the serial
> >> clock, and
> >> the DSP reads a bit on the falling edge of the clock.
> >> A seventeenth clock pulse is send during the fram pulse. The frame
> >pulse
> >> starts the transfer of a new word to the DSP. The frame pulse is
> >> detected on
> >> the falling edge of the clock pulse.
> >> The MSBit is send first . A "1" is output as high level and a "0" as
> >> low level
> >> to the BDR0 pin on the DSP.
> >> The DSP uses 1 bit data delay, which means that the first bit has to
> >be
> >> send
> >> after the frame pulse is low.
> >> We have no additional clock pulses after the 16 bits are send and
> >> before the
> >> next frame sync.
> >>
> >> Can anyone see an obvious fault in our serial bootloading of the 5402
> >> DSP ?
> >>
> >> Best regards
> >> Torgeir Jakobsen
> >> e-mail:
> >>
> >>
> >
> >
> >
> >
> > Hallo, Torgeir Jakobsen.
> I have the same problem with booting of tms320vc5416.
> All your recomendations was entirely accomplish.
> Can you take me your email to ask my questions more particular.
>
> Tks.