PCW C-compiler startup sequence & user function

[PsionicOz]

Hi,

Is there a way in the CCS PCW C-compiler to slip a small user startup function into the memory space that is called prior to the normal C start up sequence before main() ?

Specifically I need to toggle one port pin high to enable the power supply to my micro immediately after a power on reset. I can't wait the 46 or so instructions from reset to the very beginning of main().

The product is very small and I don't have the PCB real estate to place large electro caps, the clock speed is sub 250kHz already to keep the current down. The micro I'm using is the PIC 16F684 with the latest PCW compiler and tool chain.

Any help gratefully appreciated.

/M.

[FvM]

A combination of #org and #build statements should work to force execution of the code before main(). Depending on what you want to do in the startup function, assembly coding may be required.

[RF_Developer]

Having something this sensitive to startup timing is very poor hardware design practice. In any case saving a few instructions worth of time won't help. Why? Because the PIC will spend a lot of time in its reset state, tens or even hundreds of ms, while its clock runs up, and other parts of the PIC initialise. Compared to that the 46 instruction you think you'll save are but a drop in the ocean.

All hardware driven by a PIC, or any other processor, should be arrange so that it defaults to a safe state when the processor is reset. In a production environment this is vital as you don't know, and cannot predict or control, how long the processor will be in its unprogrammed state, which is generally closely related to its reset state.

PICs, like most embedded processors, all probably, default to all its IO ports being inputs, i.e. Hiz. You can use simple pull-up or pull-down resistors (historically it was always pull-ups but that was due mainly to the asymetric drive and input characteristics of TTL logic and its precesessors) to make sure what will become outputs once your code runs are in a sensible, safe start-up state.

RF Developer

[temtronic]

If we assume this is a battery powered PIC, why not just use a higher energy battery? uChip has a great ap note on calculating the power requirements of a PIC project(ADC-PIC->PC) that is well worth reading and nowadays there are batteries with a LOT of energy in them for the size.
As for space for an extra cap, I've used 4 smaller ones around the coin cell holder( in the wasted space 'corners' N-S-E-W).

As pointed out having well designed hardware is essential to getting software to run reliably !

[PsionicOz]

I see my application is picqued some interest.

The application is actually mains powered (floating), there is no shortage of power only problems with heat from linear supplies and component stress to be concerned with.

From power up the processor is held in reset by hardware until the end of the first half cycle and then released (initial charge of power supply), the processor wakes up has ~ 0.5-1ms to get its act together and force a IO pin high to enable a secondary PSU to keep things running through the next half-cycle, the boot up power supply is disabled. The closer I can get to the zero cross the better in terms of heat. Shaving off 46 instructions at 250kHz is ~0.7ms which will lower the heat dissipated by the regulators by 5-10degC. Microcurrent multiplied by mains voltages becomes tens of milliwatts very very quickly.

A combination of the LF and HF clocks are then used to balance the current consumption and heat dissipated.

Ok looks like I can override the startup sequence with the #build command and simply #org a function into the lower part of memory. I will try this today. I've read the CCS book from cover to cover and missed the one little statement about the #build(reset=<blah>) command.

Thanks for the helpful pointer

/M.

[PCM programmer]

I did this one last night. Didn't have time to post it until now.
This works if your program doesn't have an #int_xxx interrupt routine.
I don't know how to do it if you do have one. Maybe there is a way.

To see the result of this program, look at the View / Program Memory
menu in MPLAB. It shows the 4 lines that are inserted at ROM address 0.

[asmboy]

[temtronic]

Hmm...sounds like you need a better power supply design.
Two options stand out, one of the 'new' off-line switching modules or a simple C-R divider.
The first choice..you can either build your own , buy a readymade product or say go with an 'off-line' LED PSU,Most are 80-95% efficient.
The second, using a big cap in the voltage divider is an old technique, great for low current demands,eliminates the 'wasted power into heat' problem with poorly designed linear regulators. You _MUST_ remember that one leg of the 'mains' will be on the PIC!
You haven't said what your overall power requirements are,but #2 is good for several ma, #1 is good for amps.

As for linear supplies 'heating up', proper design and selection of components will minimize the 'self-heating' effects.You don't for instance ,start with a 24volt supply to run a 5 volt PIC.Working 'backwards' ,with LDO regs and minimal current demands, a simple have wave bridge using a 9v ct transfomer ,will work fine.

[Mike Walne]

Taking temtronic's suggestion a litle further. Here in the UK (230V @ 50Hz), the current available from a capacitor dropper is of the order of 70mA per uF with full wave rectification. You will need to scale up or down for different voltages and frequencies. It's safest to use an X (or even a Y) rated capacitor as they are intended for operation connected directly across the mains supply. From what you're saying you should be able to use such an arrangement very easily.

Mike

[PsionicOz]

Thanks for all the suggestions.

The power supplies of this device are fairly hairy in that it has to power steal around the zero crossings of a mains signal while shorting it's own input using MOSFET's. The device is a two wire electronic switch (with smarts of course), there is no neutral connection to the device. This means that the device bleeds a small current (<1mA) through the device to establish it's power supply. There are many products on the market that do this, nothing new.

The main problem with this method is when trying to startup the output is off, so you have full mains being applied to your resistive/capacitive dividers so you can't draw much current (<100uA). I have an auxilary linear supply that is good for 1-2mA which I can switch on and start up using 250kHz. Once I'm started I enable the output and start switching the load which reduces the linear psu disspation by 80%; the auxilary supply is what steals power from around the zero cross ~2ms every 10ms.

From there I can sequence the power supplies and clocks, so when I'm running off the LF 31kHz clock in idle mode I use a simple 3M9 bootstrap resistor (~60uA) and the auxilary supply is off. The faster I can get the auxilary power supply on and the processor started and switching the better. At the moment the auxilary PSU rise above ambient is 20-30degC for the duration of the boot up sequence, dropping this by 1ms will reduce this by half. As I've mentioned previously the 46 instructions equates to quite a bit of time ~0.8ms. If I don't get the microstarted the auxilary PSU will shutdown and hold my micro in reset until it cools off.

I'm trying FvM and PCM programmers suggestions, still trying to come to grips with what the #build command does. I've implemented FvM's suggestions and this should work for what I want. Took me a while to read and understand the C/ASM list file.

/M.