cancel
Showing results for 
Search instead for 
Did you mean: 

anybody had luck with the SPC574Kxx_RLA GTM DPLL Test Application for Discovery example?

CoolMo
Associate III

Hi everyone,

I am struggling to understand why the provided example seem not to behave as expected:

  • upon startup, when the gap is detected, the generated Reference_position (TDC) turns out to be localized 1 tooth AFTER the calculated one (angular ticks math), even if the values written to the TBU_CHANNEL1 register are correct. It looks like the match-value is only loaded into the CCU register of the ATOM channel only 1 active edge AFTER (This could be overcome with a one-time only -cold boot- compensation btw).

  • but it's not over: after a lock-loss scenario (take 1 tooth off the crankwheel, e.g.) the resynchronization procedure is carrried out following the same steps as on startup but this time (oddly enough) the Reference_position (TDC) ends up 3 teeth (angular position) BEFORE where it is expected. There must be something with the CPU loading the CCU register values for next matching...

0693W000008GRGjQAO.png 

Is there anybody running into similar issues on this specific platform? How did you get over (if you did)?

M

1 ACCEPTED SOLUTION

Accepted Solutions

There is no direct function but you can leverage on the clock signal routings internal to the GTM.

You can expose the subinc1 pulses to a TOM channel output, at a half of the real freqeuncy:

  • configure the CMU of the GTM so that CMU_FXCLK0 is fed by [CMU_CLK7 / (2^0)] and make sure you set CMU_CLK7.SEL = 1. This last setting will route the subinc1 pulses from the DPLL to CMU_CLK7 output
  • Then pick a TOM channel (e.g. TOM1[4]), choose CMU_FXCLK0 as it clock source and enter 2 for Period and 1 for Duty-cycle
  • configure the SIUL2 to route the TOM output to the output pin you choose

the TOM channel output will 'track' subinc1 pulses at half of its speed. I use this to investigate when the DPLL actually starts/stops generating subinc1 pulses in response to setting changes

View solution in original post

9 REPLIES 9
JHoll.1
Associate II

I can't answer the question but I am about to start working on this on an SPC572L. Have you read the Bosch application notes gtm_ip_an011_dpll_v04, and AN012 and AN013?

Of course I did.

The Test Application I am experimenting with (which ships with SPC5Studio) is largely based on them.

Once you'll have your SPC572L platform up and running, please post your success case of missing-tooth scenario and full resync procedure (it'll be interesting to see if injections/ignitions are preserved upon DPLL is locked again on the profile)

Hamid1
Associate II

As I looked on pulses , it looks wrong ,, fly wheel has 60 teeth usually, which mode is fly ? which car?

The example provided with SPC5Studio for the Discovery board can run with different flywheel confgurations. Here I am experimenting by simulating a 24-2 flywheel. The number of teeth is not the problem.

JQuin.4
Associate

Hi, i am not expert in this. The new_value interrupt is disabled when missing tooth is detected and I think that is not enable with others interrupts. Maybe you can try re-enable the new_ value with missing tooth interrupt (dpll_mti_ interrupt) or lock_loss_ interrupt and restart the sync process.

CoolMo
Associate III

Ok, it looks like I'm the only one who struggled with this. So here is my solution (which came after quite some non-painless testing):

  • to prevent the 1 tooth DELAY on the programmed reference position after the gap is first detected, make sure you subtract to the offset value you are displacing the position to an amount equivalent to 1 tooth in microticks (TOOH_MULTIPLIER). This wil displace your 'future' reference position in a coherent manner with the angular events you may schedule at the moment you are detcting the gap. Successive reference position updates, instead, can be displaced of exactly of one or two complete crankwheel cycles directly when the reference_position isr handler is executed.

  • in the missing_tooth-lockloss-relock scenario, in orde to make sure the microticks count stops without messing up your reference, you will want to disable DPLL subinc1 generation right at the lock-loss isr handling by calling gtm_dpllDisableSubInc1(). This ensures that no microticks are generated until they are needed: when the gap will be detected again (followed by DPLL re-sync, etc.)

Hopefully this can be of use if you are confused about what is going on in the process.

Good solution, I'll try it. another question, how can you display the subinc (TBU_CHANNEL1) ? any function for it?

There is no direct function but you can leverage on the clock signal routings internal to the GTM.

You can expose the subinc1 pulses to a TOM channel output, at a half of the real freqeuncy:

  • configure the CMU of the GTM so that CMU_FXCLK0 is fed by [CMU_CLK7 / (2^0)] and make sure you set CMU_CLK7.SEL = 1. This last setting will route the subinc1 pulses from the DPLL to CMU_CLK7 output
  • Then pick a TOM channel (e.g. TOM1[4]), choose CMU_FXCLK0 as it clock source and enter 2 for Period and 1 for Duty-cycle
  • configure the SIUL2 to route the TOM output to the output pin you choose

the TOM channel output will 'track' subinc1 pulses at half of its speed. I use this to investigate when the DPLL actually starts/stops generating subinc1 pulses in response to setting changes

Hi  Jholl,

Are you there? Had you successfully downloaded AN013 from BOSCH? Thanks!