ATtiny1616 -> CCL LUT And Edge Detection Woes

Go To Last Post
17 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This problem is killing me. I've been on it for two days now and wondering if I just have stuck with PIC16.

 

Inputs (all working)

 

AC0 -> Over Voltage
AC1 -> Normal Voltage
AC2 -> Zero Cross

 

Logic (not working)

 

TMRB0 -> Frequency measuring using AC2, event piped through to LUT0

LUT0 (EVENT0=TMRB0, EVENT1=AC1) -> S
LUT1 (AC0) -> R

 

Output (working)

 

TMRD Deadband control
 

Problem 1

 

The reason for piping TMRB0 through instead of using AC2 event directly is LUT0 does not support falling edge detection. What they say in the datasheet is to invert the logic, which is ridiculous as it doesn't change the edge it's monitoring, and besides which there are three channels driving the logic. I tried and it doesn't work. I also tried inverting the AC2 output with no joy (Event system must bypass the inversion).

 

 

TMRB on the other hand supports falling edge so it sounds promising. Go with that...

 

Problem 2

 

When over-voltage occurs the latch goes low and TMRD deadband kicks in. This works. TMRB resets the latch at zero-cross (ish) and it starts over. This is good as I've managed.

 

Ideally I'd like to wait until the voltage has reached a normal level, which comes from AC1. It sounds easy enough to make the logic =1 when AC1=0 and the pulse comes in from TMRB. To test, I set AC1 to use the same voltage point as AC0 - in other words it should be logic 0 immediately or thereabouts so make little difference.

 

What actually occurs seems to be a hardware bug, let's see it on the scope.

 

 

You can see it's took three AC cycles for the device to hit the over-voltage. With AC1 event it then takes 16 cycles (always 16!) before the latch will reset which, because it's based on some type of counting typically results in the device going into uvlo and resetting. I'm unable to resolve this condition no matter the parameters of the LUT, sync options or AC1. I also replaced AC1 with AC0 and the same occurred, so it appears some quasi logic is going on when two LUT-IN-X channels are used for deriving the logic. 

 

Any ideas most welcome!

Last Edited: Wed. Oct 14, 2020 - 06:10 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Back up and tell the actual problem your trying to solve( the big picture ), rather then your failures at trying to solve it, please. 

A freak may have already solved it.

 

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Three states into SR gate logic controlling the deadband of TMRD. These may help visualise the problem.

Note I've wired the LUT outputs through the EVENT system to create an SR here. It was my attempt to see if the built in CCL SR was the issue. LINK is broken (device errata). Problem remains the same.

 

 

 

Last Edited: Wed. Oct 14, 2020 - 07:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

 

Instead of using the builtin latch you can make one if you still have a spare LUT. It may have faster response.

 

 

This is a truth table from a program where I implemented this

 

  /* RS latch truth table
    -----------------------------------------------------------
    R     1   0   1   0   1   0   1   0   (LUT IN0)
    S     1   1   0   0   1   1   0   0   (LUT IN1)
    FB    1   1   1   1   0   0   0   0   (LUT IN2)
    -----------------------------------------------------------
    OUT   1   1   0   1   0   1   0   0   (LUT truth register)
    -----------------------------------------------------------

    FB = feedback from previous output
    R = reset (forces out = low)
    S = set (forces out = high)
    OUT = output
  */

 

Note than on a "normal" RS latch, R,S = (1,1) is not legal, I fixed this so that both (0,0) and (1,1) keep the value from feedback (no change). But with a LUT you can create any behaviour you want.

Last Edited: Wed. Oct 14, 2020 - 07:14 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nice, I'm one step ahead. wink Been doing that since posting and just updated the post before your own. Sadly no luck - it works but with the same huge delay once the second input is used alongside the TMRB event.

 

I'm beginning to think this chip was not ready for release, too many bugs.

Last Edited: Wed. Oct 14, 2020 - 07:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I wonder where such huge delay is coming from? I never encountered anything like that. It's like you are clocking the LUT with your signal.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm not a believer in coincidences, look at this...

 

 

14.4v is correct. 7.2v is half, and I've no idea where that's coming from. Both AC0 and AC1 are using the same positive pins and both have set neg set to Vref (1.1v). It's as if AC1 is using the 0.55v ref!

Bet it's a bug in MCC, heap of shit that it is!

Last Edited: Wed. Oct 14, 2020 - 09:23 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

After two days it's working :). Dropped MCC now as it really is a steaming turd for the 1616.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You neglect some important info--- What kind of frequency range do you need to measure?  1 KH to 50 KHz? 2HZ to 20 MHZ? ---you need to match your method to the range.  How accurate do you need:  0.0001 Hz? , 0.03 Hz?   At low freq, you can easily use a timer and IRq's to do the measurement gating.   If you need to measure to 8 digits resolution in 1 second that is much more difficult.

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This was not a measurement exercise but one of controlling hardware (aka working as a glue chip). It had to be done without CPU intervention - if the timing is wrong, or crashed etc, it could overheat the zener (last resort protection) and fry the board.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This was not a measurement exercise but one of controlling hardware (aka working as a glue chip). It had to be done without CPU intervention - if the timing is wrong, or crashed etc, it could overheat the zener (last resort protection) and fry the board.

You should at least take time to explain it..what is your board/circuit/program supposed to do? Run an elevator, or control a beer cooler? ?  That should be the first step!  it could overheat the zener   Zener?  What zener are you talking about & how would this cause it to get overheated?

 

and fry the board    ...include your fusing (though admittedly, fusing can be lame protection).

When in the dark remember-the future looks brighter than ever.   I look forward to being able to predict the future!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

avrcandies wrote:
You should at least take time to explain it..what is your board/circuit/program supposed to do?

The same question was asked in #2, still waiting for an answer.

This tread is a classic XY problem. https://en.wikipedia.org/wiki/XY...

 

Jim

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

Last Edited: Thu. Oct 15, 2020 - 12:58 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
This tread is a classic XY problem. https://en.wikipedia.org/wiki/XY... 

Indeed.

 

See also: http://www.catb.org/esr/faqs/smart-questions.html#goal

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks like some above MCU safe voltages from outside the chip interacting with the chip. Whats your support circuitry for safe voltage/current on the MCU? Does the system clock effect the CCL, what are the filter settings, can it be done with the AC(she's fast)? Is the test output control pin switched via software or hardware? Should you test the logic with a signal generator or simpler setup instead? Also, these helpful veterans like to see your simplified code to test only the problem your working on.

Bugs may occur do to outside parameters. I found one specifically on my project (attiny1614) where a battery charger chip would wake up the MCU from sleep mode by pulling an MCU pin low through a mosfet on the charger chip. It would however not enter the corresponding ISR. I could pull that same line low with a wire to ground and this would enter the ISR! Bugs happen.

~William

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The problem is the 1616 is full of bugs. I'd go back to the PIC16 if I was starting over but I'm too far along. I'd also ditch Microchip completely for what they've done with MPLABX but they've cornered the 5v market.

Last Edited: Thu. Oct 15, 2020 - 05:20 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

vertamps wrote:
It would however not enter the corresponding ISR. I could pull that same line low with a wire to ground and this would enter the ISR! Bugs happen.

Not sure I would call that a bug, as the datasheet clearly states, the line must be held low, long enough to exceed the startup delay of the chip before the ISR will fire.

Yes a quick pulse of the line will do the wake up and skip the Interrupt...  smiley

 

Note: Note that if a level triggered interrupt is used for wake-up from Power-down, the required level must be held long
enough for the MCU to complete the wake-up to trigger the level interrupt
. If the level disappears before the end of
the Start-up Time, the MCU will still wake up, but no interrupt will be generated.
The start-up time is defined by the
SUT and CKSEL Fuses

 

Jim

 

 

(Possum Lodge oath) Quando omni flunkus, moritati.

"I thought growing old would take longer"

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Gonna hook the scope up tomorrow and see if the charger chip logic pins are bouncy on startup,its been so long i dont remember if i did that. My workaround was checking if the power on button was triggered as that ISR worked. I actually was back on the project this week modifying code to debounce the usb power cable being plugged into a battery pack.

~William