• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 32 subscribers
  • Views 709 views
  • Users 0 members are here
Support feedback
Options
Options

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.

Hercules launchpad + halcogen = speed issue

Madalin Huzum
Prodigy 20 points
Other Parts Discussed in Thread: HALCOGEN, LAUNCHXL-RM42

Hello all,


I'm having a very frustrating issue:

Take one LaunchXL-RM42 and one HALCOGEN.

Create a default project in halcogen for this microcontroller and  use the HET, for example. (http://processors.wiki.ti.com/images/2/26/Hercules_LaunchPad_Proj0.pdf should fit the bill)

What I discovered is that the real speed at which the microcontroller is running is 10 times smaller than the speed halcoged expects it to. ( one sets the led to blink at 1 second and it does at 10 seconds)

Halcogen expects 100MHz (16MHz external osc). The external oscillator on the hercules launchpad seems to be 16MHz , yet, using the defaults in hacogen, I get gibberish.

Initially I started with this: http://focus.ti.com/docs/training/catalog/events/event.jhtml?sku=OLT212021

I only get gibberish from the MCU ( I never even expected to actually have it do the loopback). I used a scope to see what was happening (what i got from the scope) and indeed, for a 115200 baud from halcogen, i got something closer to 9600 on the scope, but on top of that, the character I sent was not the same as the one i intended to send.( e.g. I tried to sent an 'a' using the MCU but on the scope it did not look even remote to an 'a' sent using a FT232 uart from a computer (bitwise). It was still an uart character, but not the same composition of ones and zeros (did not bother to identify them since it was pretty obvious it was sci-fi(not even reverted polarity))).

Did anyone get this sort of odd behavior? Is it a knows issue? Or did I mess up something regarding the clocks in HalCoGen and I forgot about it?

Is the Osc for the launchpad 16MHz?
 Mine has T160=H74 written on it. I'm betting that it is not 1.6 MHz.

Did I stumble onto something, or am I the most unlucky MCU fan on this forum?

  • 0
    Guru 15740 points

    That same example works without problems on the Hercules TMS570 launchpad  for me (runs at 80 MHz).

    Can you upload the HalCoGen project? I'll do  a step by step follow up of the tutorial for your processor and check if my HalCogen settings in the end are the same as yours.

  • 0
    TI__Guru 68830 points

    Madalin,

    Sorry this is frustrating.  I don't think the crystal is a problem.  My launchpad also has a crystal that says T160 and I believe it's correct.   And the device has clock fail detection that typically trips below 2.4MHz.

    I think you are seeing the device running off of it's LPO - HF oscillator.   This could be a configuration problem, or it could be that the device detected a clock fail and switched over to this on chip oscillator.

    It's possible that you selected the LPO as the clock source by mistake in HalCoGen,  so I would double check that first.

    You might want to skim section 9.2, 9.3, and 9.4 of http://www.ti.com/general/docs/lit/getliterature.tsp?baseLiteratureNumber=spnu516&fileType=pdf and possibly the sections that follow to get an idea of how the clocking system works.

    Then you might check section 9.4.3 - it tells you what bits are set if the device detected an osc fail and switched to the LPO on it's own and it also tells you how to recover.  Of course at some point it would be good to make sure that your oscillator is actually running.  If you have a high impedance / low capacitance scope probe you can usually probe the osc without killing it.   Some cheaper probes may kill the oscillation though - so just beware.  

    Let us know what you find.

  • 0 in reply to Anthony F. Seely
    Prodigy 20 points

    First,

    Thank you all for your input on this issue :) .

    The answer Anthony gave was partially usefull in the sense that it pointed me to a way to debug the issue.

    I read the documentation you pointed me to, so I verified the clock source settings. The clock source was set to PLL, as normal, but with a 100 MHz  PLL 1 setting, the MCU was running as I described ( 10 times slower).

    My first attempt to debug was ramping down the PLL to 50 MHz, and indeed, I noticed how now, the blink rate was 5 seconds instead of 10 (which meant the  clock source was the PLL this time for sure, which was 5 times faster than the internal, theoretical 10 MHz source it would appear to be using before) .


    But then I realized that, HALCOGEN should have compensated for the new frequency of the PLL and adjusted the dividers for the timers accordingly.  In the end, the blink rate was still supposed to be 1 second( with the now working PLL clock source, not 5 seconds).

    I looked in HALCOGEN and indeed, the dividers were automatically changed to compensate for the 50 MHz clock, yet still, the blink rate was not the intended one. Don't understand why this is happening and it is not worth investigating any further since I decided to move on to the RM48 family since there are no issues of this sort. Everything works out of the box.

    Thank you very much again for the time  you invested in helping me :)


    I wish you all the best and may your MCUs never hit the error interrupt handler :)