topic MC9S12 mode trace analyzer? in S12 / MagniV Microcontrollers

MC9S12 mode trace analyzer?

rafaelodamiani — Tue, 30 Jan 2018 19:15:17 GMT

Hi, I need a way, to capture variables such as, cycles X ISR (TCNT) X overflows X DeltaTime (variables) X etc. For the sake of study, I want to understand the logic of functioning ...

--------------------

software
* CW 5.9
* Truetime simulator 6.1
* MCU MC9S12
* is connected with a USBBDM.

--------------------

The PCB is capturing an ISR interrupt, with a square digital signal on that port. the system works perfectly, including the code and its operation.

I just want to understand the hardware operation ... and for this I need a tool to NOT stop the time. Unfortunately breakpoint does not work for this, the most suitable would be a dataloger (trace).

code:
I need to understand the logic of this:

  if (! (TFLG2 & 0x80) || (TCNT <TC2)) {
    if (! ICt_overflow) // no overflow
      dt3 = t_in3 - t_in2;
    else {
      dt3 = t_in3 + ((long) ICt_overflow * 43690) - t_in2;
      ICt_overflow = 0;
    }
} else {
dt3 = t_in3 + ((long) (ICt_overflow + 1) * 43690) - t_in2;
ICt_overflow = 0;
}

obs: a part I already understood. others only analyzing the values and comparing, and for this a datalog is fundamental.

obs II: I understand the concept of overflow, I just do not understand "(TFLG2 & 0x80) || (TCNT <TC2)"

TFLG2 & 0x80 is when an overflow occurs. in your ISR (overflow) then it is cleaned (flag). What I do not understand is when the ISR (TC2) opts for (TFLG2 & 0x80) or (! TFLG2 & 0x80)

example: if the ISR (TC2) activate at the exact moment of the overflow x0000 what would happen?

sorry for so many questions, a datalogger would help me hehehehe

Re: MC9S12 mode trace analyzer?

RadekS — Wed, 31 Jan 2018 17:29:08 GMT

Hi Rafaelo,

I am also not sure whether I understood correctly to your code.

Obviously, it is code for input capture period calculation.

Slightly strange is “((long) ICt_overflow * 43690)” code part (43690=0xAAAA). We typically let TCNT register free running and calculate with 65535 (0xFFFF) value for one overflow. This looks like that one of timer channels (typically the last one OC7) is configured for counter overflow event.

I suppose that (! (TFLG2 & 0x80) || (TCNT <TC2)) simply present that the new overflow already occurred.

TCNT is the free running counter, TC2 contains last captured value. So, if TCNT is smaller than TC2, there must be some overflow already - just before we started with this calculation and before it is serviced by ISR (ISR execution may be delayed by any higher priority interrupt).

I guess, that this may locally solve some very specific cases where an event occurs really around this code processing time point (when overflow is not serviced yet,….)

About trace)

"c:\Program Files (x86)\Freescale\CWS12v5.2\Help\pdf\Debugger_HC12.pdf"

This document described Trace component. Unfortunately, I don’t have any personal experience with such feature.

Optionally you may use FreeMaster tool for runtime debugging. But I am afraid that this tool probably cannot help you with this specific request.

I hope it helps you.

Radek

Re: MC9S12 mode trace analyzer?

rafaelodamiani — Wed, 31 Jan 2018 19:29:28 GMT

Hi, Radek.

more informations...

*yes, the code is to capture period. precisely capture vehicle speed sensor

*43690 are in usec, not 16 bits (43690 * 3 / 2 = 65535). 43692 is an prescale configuration type(tick 0.666usec*65535 = 43692usec).

*correct, TC2 channel 2 is configured like input.

obs: I forgot to report, this code is inside the ISR TC2, Of course, whenever a level rise occurs, it is called the interruption TC2 on vector map.

--------------------

oh, is true! I have forgotten this detail of the past,present and the future. overflows are not easy to understand, because several situations may occur, and the code above shows this.

obs:

overflow ISR < priority than IC ISR

At least here it is configured so. ISR TCx come in first.

correct, in special ISR may be happen. I remember having failed in the period of this capture in a long capturing encounter

> 5min, spike very fast velocity or very long. after I copied that code ended that.

my simple code was just that. spike can be happen

   if (! ICt_overflow) // no overflow
      dt3 = t_in3 - t_in2;
    else {
      dt3 = t_in3 + ((long) ICt_overflow * 43690) - t_in2;
      ICt_overflow = 0;
    }

obs:

t_in2(last tc2 usec)

t_in3(new tc2 usec)

dt3(delta usec)

-------------------

original code with tips

  // Need to test for overflow because overflow ISR < priority than

  //  IC ISR and might be pending, so ICt_overflow not up to date.

  if (!(TFLG2 & 0x80) || (TCNT < TC0))  {  // check for t overflow isr pending

    // no pending overflow isr or IC occurred < overflow

    if(!ICt_overflow)

      dt3 = t_in3 - t_in2;

    else  {

      dt3 = t_in3 + ((long)ICt_overflow * 43690) - t_in2;

      ICt_overflow = 0;

  else  {

          // pending overflow isr and IC after overflow

    dt3 = t_in3 + ((long)(ICt_overflow + 1) * 43690) - t_in2;

    ICt_overflow = -1;      // pending, so -1 will cause to clear in isr

--------------------

trace, me too.... i am fully noob. Maybe I want too much. I do not know if it has any correct tools, I was thinking of making a serial connection software, and capture those values and make a datalog. But I have to work for it. and a ready program would be great!

Re: MC9S12 mode trace analyzer?

RadekS — Fri, 02 Feb 2018 15:58:58 GMT

Hi Rafaelo,

Thank you for the explanation about the units.

Note: It is rather an unusual approach to do such multiply and divide operation inside ISR.

In general, that ISR should be shortest as possible and multiply and divide operation are rather long instructions. So, we typically use this range formatting (from tics to us) in the main loop when we want to present the output. But this is application specific and you may have a reason for that.

Regarding capturing data and datalog)

Definitely, I would like to recommend FreeMaster for such task.

Radek

Re: MC9S12 mode trace analyzer?

rafaelodamiani — Sat, 03 Feb 2018 04:43:11 GMT

Dae Radek, teu BR confirmou oque ja suspeitava, comprei de ti um bootlooder Atmel a anos atras hehehe. vo toca no ingles pra nao ser banido.

------------------

*yes, operations in ISR only possible mode BITWISE. like that <<1, or, and, >>7, etc. Else, it can be great problem. ASM is possible would be better.

-------------------

I already downloaded the software, I will use it, it seems complete.

Re: MC9S12 mode trace analyzer?

RadekS — Mon, 05 Feb 2018 09:32:15 GMT

Hi Rafaelo,

Unfortunately, I am not sure whether I understood correctly to your last comment.

The Portuguese is not my native language and Google translator didn’t help me so much.

BR means Best Regards and I never work with Atmel chips before. I just wrote a bootloaders for S12(X/Z) devices.

If I understood correctly, the original issue was caused by flag clearing mechanism. Correct?

AN2554 Clearing and Disabling Interrupt Flags

http://www.nxp.com/files/microcontrollers/doc/app_note/AN2554.pdf

Best regards

Radek

Re: MC9S12 mode trace analyzer?

rafaelodamiani — Mon, 05 Feb 2018 13:48:40 GMT

hello sorry rrsrsrs
I thought you were a seller here in Brazil. has the same name. this is at least 3 years ago. I saw the 'BR' I thought was an abbreviation for Brazil.

------------------------

yes, I understood.

works as follows. I'll put the steps in the order of time and execution. It's a bit tricky but that's how it works!

example of any capture:
1st: ISR "TC2" triggered! (57871), LAST, ICt_overflow == 0,
2nd: ISR "TC2" triggered! (0), NEW, ICt_overflow == 0
3rd: now we have a "problem"! (ELSE block was called). FLAG ON overflow (x0000)
4th priority of execution, 1st ISR TCx.
5th ISR TC2 execution, question, overflow ?, YES (FLAG is ON)
6th ICt_overflow is forced to receive +1, in order to calculate and not give calculation problem.
7th ICt_overflow is removed by with put -1. in next step, precisely because the ISR overflow will be called next and there will gain increment in that variable.
8th ISR overflow (1), one tick after, ICt_overflow +1, FLAG OFF

process concluded!

is relatively simple, ELSE only works on the exact overflow. but I have not yet studied (TCNT <TC2) ...

that's why sometimes it happened to hit spikes at random. because I had not put these conditions.

---------------------

Thanks for the document, I'll read it.

Re: MC9S12 mode trace analyzer?

RadekS — Mon, 05 Feb 2018 14:48:02 GMT

Hi Rafaelo,

Your note in Portuguese is now clear.

I am from Czech Republic (Central Europe) and Radek is here quite a common name. I guess that that seller from Brazil had some parentage from our area.

Thank you for procedure description.

Anyway, which S12 MCU family you use? The families with S12X, S12Z cores may change ISR priorities.

Radek

Re: MC9S12 mode trace analyzer?

rafaelodamiani — Mon, 05 Feb 2018 15:24:20 GMT

hi, cool, I'm from the south of Brazil, here there are many immigrants there are many immigrants here, Italians, Germans, Arabs, Japanese, Czechs

I use S12C

Re: MC9S12 mode trace analyzer?

RadekS — Mon, 05 Feb 2018 16:01:37 GMT

Hi Rafaelo,

Ok.

Unfortunately, there isn’t any hardware ISR priority feature at S12C.

The only option for prioritization or nesting is pure software solution as per AN2617 A Software Priority Interrupt Scheme on HCS12 Microcontrollers

http://www.nxp.com/files/microcontrollers/doc/app_note/AN2617.pdf

http://www.nxp.com/webapp/sps/download/license.jsp?colCode=AN2617SW

Best Regards

Radek