Microcontroller is DALI connected but has no external oscillator crystal

[treez]

We have some lamps with a DALI dimming facility.
The PIC micro in the lamp is using its internal oscillator. Do you think this micro will have difficulty “locking in” to the incoming DALI signals?
Is it "standard practice" to always have an external oscillator?
Some of the units are not working, and we wonder if this is the cause.

 

[kripacharya]

Internal oscillators can often be off by 3%, and vary by temperature.
However if your DALI device is from a branded manufacturer, surely they would have taken that into consideration.

Also from what little I know, the initial introduction of a device into a network requires a "commissioning" to be done. I am sure you are aware of this and have done so.

Were these originally working, and are not not-working ? Or are they new, and maybe from a different manufacturer ?

 

[treez]

We are finding that some units work and some dont

 

[Aussie Susan]

As you mentioned a PIC device, Microchip have an App Note (https://ww1.microchip.com/downloads/en/AppNotes/01465A.pdf) that uses a PIC16F1947 which, according to the schematic in the app note, is running from the internal oscillator (as no external crystal is shown).
The App note also shows in text in Figure 7 that the timing required if +/-10%. Even at the widest temperature range fort that chip, the data sheet shows that the HFINTOSC is +/-5% (with the +/-3% mentioned above as the more typical operating temperature range).
Based on the App Note and the data sheet for the MCU mentioned in the App Note then there is every chance that the design can be reliable. However we don't know the actual MCU used in your case nor the schematic etc. and they will have a major influence on reliability.
Susan

 

[treez]

Thanks, we are still struggling with our microcontroller sometimes being able to act on the DALI signal , and sometimes it isnt...as follows...please could you offer any help?...

Hello,
We have a PIC18F26K20 micro which is receiving DALI dimming signals and then (supposed to be ) dimming a non SMPS based offline LED driver. Everything is non-isolated.
The micro has a 2V5 supply rail.
The micro is grounded to the post mains rectifier DC bus “ground”. The PCB on which the micro is placed sits on top of the earthed heatsink.
We are finding that the first time we power up a newly produced PCB, it works fine, (usually).
However, the second and therafter times that we power it up, it correcetly goes through its slow dim-up routine, but then fails to respond to DALI dimming signals thereafter.
We are wondering if this is a problem that the micro’s internal oscillator may not be able to “sync-up” to the incoming DALI signals when it gets hot, and so it stops working. We wonder if a shot of freezer spray onthe micro should be our next step? Maybe as the micro temperature goes up its oscillator goes haywire?
We would like to ask the software engineer to slow down the DALI data rate to make it easier for the micro to receive the data , but the software engineer has left.
Do you think freezer spray on the micro will help?

 

[Aussie Susan]

If the problem is that the MCU is getting hot then that is the problem you should sort out first. And freezer spray is NOT the way to go - that only alters a symptom and not the cause.
Susan

 

[treez]

Thanks, but we dont yet know if the micro getting hot is causing the problem..

 

[Aussie Susan]

It may well be but *THAT* is not your problem - *THAT* is not what you need to find and fix.
I mean, imagine that the MCU getting hot is causing the fault you describe. What will be your solution? Install a very large canister of 'freeze'?
There is a 'truism' in engineering: you will solve the problem you define so make sure that you define the right problem.
Susan

 

[FvM]

I notice that DALI is using a non-standard 16 data bit UART protocol. Respectively the tolerable oscillator drift is only half of a 8-bit standard UART. The software might however implement baud rate adaption. On the other side, there must be some kind of 16-bit software UART in your design. Are you sure that it's reliable?

Another point to consider, datasheet specifications about internal oscillator tolerances are only valid if the chip is free from mechanical stress like PCB warping.

 

[treez]

does anybody know if pic18f26k20 is an 8 bit pic, that can be programmed with the free xc8 c compiler?

Our software guy has now just walked off...telling us his software doesnt work because our hardware is injecting noise into the pic and corrupting his code.
So we have to write some simple code to run on it, and see if it does it...or gets corrupted by this "noise".

Its an offline led driver (non smps based) and the pic is grounded to the post rectifier dc bus and theres no ac mains filter, so its been said theres going to be loads of mains bourne noise...i doubt it but we must proove.

 

[FvM]

does anybody know if pic18f26k20 is an 8 bit pic, that can be programmed with the free xc8 c compiler?

Sure it is.

 

[Aussie Susan]

Does this mean that you have solved the overheating problem? If not then you are still chasing phantoms.

Our software guy has now just walked off...telling us his software doesnt work because our hardware is injecting noise into the pic and corrupting his code.
So we have to write some simple code to run on it, and see if it does it...or gets corrupted by this "noise".

Is this the correct way to test this? What sort of code do you expect to write that will prove if the hardware is injecting noise or not?
I would try to run the code in a different hardware environment that uses a high quality bench PSU and input coming from a 'known good' (i.e. noise free) source. That way you can tell if the software works in a "good" environment or not. If not then the software is the problem; if it does work then you need to look elsewhere.
If the hardware is suspected of injecting noise then a scope will tell you this? Check the Vcc line and it should be smooth. Check the input lines and they should transition cleanly with no noise on the high and low levels.
Susan

 

[treez]

Thanks, i think your test will be our first port of call today.
Then i have this sneaking feeling that we havent been erasing the pic's before programming them.....would that have any effect?

 

[Aussie Susan]

You have said that you are using the XC8 compiler so can we assume that you are using the MPLABx IDE and perhaps something like a PicKit3 programmer? If so then the first step is to erase the FLASH memory before programming.
The way that FLASH memory programming works for these devices is that the erase state sets all of the bits to '1' and the programming process sets the appropriate bits to '0' to form the correct instructions etc.. If the FLASH memory was not erase before programming then some additional bits would be transitioned from '1' to '0' but none the other way around. I suspect that you would end up with a totally unworkable mess - it might get to execute a few instructions before it came across an illegal instruction or addressing trap that would stop everything.
Bottom line - I seriously doubt that you are not erasing the device before programming it.
Susan

 

[treez]

Thanks

As you can gather, our microcontroller is not responding to DALI commands from the “Terminal Deploy” application. Therefore we need to test it.
For some reason the USB port on my computer will not send DALI commands to the PCB. However, my boss’s laptop will. The problem is my boss needs to use his laptop. How do I make the USB port on my computer interface with the “terminal deploy” program and send DALI signals?

 

[Aussie Susan]

I suspect that some very basic fault finding activities will help here:
- what are the differences between the boss's laptop and your computer: OS, USB driver, settings, program doing the accessing in the PC, cabling....
- which of the differences can you change so your computer is more like the boss's
Susan

 

[treez]

Thanks, also, do you know why our software engineer has set the PIC18F26K20 internal oscillator to 16MHz? After all, the DALI comms protocol is only 1200bit/sec...why has he set the osc frequency so unecessarily high?...surely its just going to make it more susceptible to noise?
I would have thought for DALI, the PIC18F26K20 oscillator frequency could be set to about 100kHz or therabouts and still easily manage to receive the 1200bit/sec DALI commands?

 

[Aussie Susan]

I don't think we can help you with why someone else made a certain decision - in this case about the clock speed being used. However the internal oscillator (HFINTOSC) works at 16MHZ (the alternative is the 32KHz LFINTOSC oscillator but that is normally used for other things) and therefore this is a common choice. There is a post-scalar that can divide this worn by various factors of 2 if necessary.
Other factors such as the sampling frequency of the comms protocol also come into the frequency selection decision. For example, the UART hardware in many Microchip MCUs have a 16x sampling so that 1200bits/sec would need a clock of 19.2KHz.
I don't think that the internal oscillator frequency would have much relationship with 'noise'. Noise can typically be suppressed external to the MCU.
Higher oscillator rates can lead to higher power consumption by the rest of the chip but whether this is important is really determined by other factors (such as the power source etc.).
Susan

 

[treez]

Higher oscillator rates can lead to higher power consumption by the rest of the chip but whether this is important is really determined by other factors (such as the power source etc.).

Thankyou and that it is an excellent point, our micro is supplied by a linear regulator from rectified mains DC bus...so we need to use as little current as possible in the micro, to stop the linear regulator from overheating.
This is a massive reason to use the lowest possible oscillator frequency.
-However, our software guy has chosen 16MHz.
Surely this is a mistake?
The product is simply a LED lamp which can be dimmed up and down, thats about it.

Other factors such as the sampling frequency of the comms protocol also come into the frequency selection decision. For example, the UART hardware in many Microchip MCUs have a 16x sampling so that 1200bits/sec would need a clock of 19.2KHz.

Thanks, So are you saying that we could have gotten away with a osc frequency of 19.2kHz or therabouts? Bearing in mind its just a LED lamp with dimming. (via DALI)

- - - Updated - - -

We are growing suspicious of software mistakes in our product (some of the PCBs work and some dont)....we were there till 10pm last night, thats when we realised that he'd written code and incorrectly defined two unused, unconnected pins as inputs....this surely is a big error?..its just inviting noise to come in (there was no internal pullup on these pins)....and each pin has a "blind" track going out to a via which doesnt connect anywhere on the PCB...so like an antenna....making it even worse.

- - - Updated - - -

The code also for some reason has a Random Number Generator function, and also stores values into EEPROM, and reads from EEPROM. The software engineer tells us that these features are necessary for DALI dimming.
Is this correct?
The random number generator could be the reason that the program just hangs every now and again and stops dimming the LEDs. Also, maybe the micro is reading EEPROM values and hanging. Some of the PCBs work on first power up but not on subsequent power ups.

- - - Updated - - -

I don't think that the internal oscillator frequency would have much relationship with 'noise'.

Thanks, is it only external oscillator crystals that give a noise problem? I thought that generally the higher the osc frequency (internal or external), the less the immunity to noise issues?

 

[betwixt]

Lets get some things clarified:

1. supply borne noise and clock frequency have no correlation. Fast clock just means faster software operation but is not more susceptible to noise.
2. The 16MHz internal clock does not 'sync up' to anything, it is an independent signal source.
3. Even if you take a worst case +/- 5% of the 16MHz clock, dividing it down to 1200 bauds bit rate will mean very little difference after division.
4. Floating inputs are a BAD idea but before shooting the software author, check they have not enabled internal pull-ups or similar.
5. Almost all PIC inputs have internal static protection so while noting 5. above, bear in mind that damage is still fairly unlikely and will not be intermittent.
6. EEPROM may be used to save the current lighting state so it can be restored after a power failure or being turned off and on again.
7. Unless there is a random lighting mode (multi color 'mood lighting' perhaps) I can't see why a random number generator is needed.

Presumably (I'm not a DALI expert) if it uses 16-bit serial data, it is bit-banged rather than using the UART, this should be easy to debug. Do you have a logic analyzer to hand?
In cases where serial data is causing problems I rely on my old Salae 'Logic 8' because it can monitor up to 8 channels simultaneously therefore see DALI outbound as well as inbound traffic and it can also accurately measure bit widths. You need to take a 'divide and conquer' approach and see if the problem is wrong data being sent or wrong interpretation of the reply or, as I suspect, a more basic design problem making the controller unreliable.

Brian.