18M2+ unreliable at 32MHz (m32) at 3.3V?

D

DamonHD

Senior Member
Hi,

I'm having some odd behaviour talking to an RFM22; I have to send it 40+ bytes of data to send to its FIFO ready to transmit plus other sundry things, and bit-banging was all taking too long.

So I cranked up the PICAXE speed with setfreq m32 which all works fine except for a very small part of the code polling the RFM22's status registers looking for the interrupt to indicate that the packet (FIFO content) has been sent after I've put the RFM22 in TX mode.

If I run that one small part faster than 8MHz (setfreq m8) it becomes very unreliable on my soldered-up strip-board but is still OK on a breadboard for the same circuit. There are some decoupling caps on both (in fact an extra one on the soldered board).

I was wondering if the 18M2+ is marginal at 3.3V at 16MHz or above while doing significant (SPI, in this case) I/O, for example? The RFM22 is probably pulling hard on the supply lines and injecting lots of RF all over the place at that point.

The code is LONG but I can point to it if anyone wants a laugh.

I have a work-round but it appals me so much that I've spent the whole day trying to work round my workround!

Rgds

Damon
 
S

srnet

Senior Member
DamonHD said:
If I run that one small part faster than 8MHz (setfreq m8) it becomes very unreliable on my soldered-up strip-board but is still OK on a breadboard for the same circuit. There are some decoupling caps on both (in fact an extra one on the soldered board)
Click to expand...
So to summarise, the breadboard layout, which you would normally expect to make a fast moving circuit with lots of RF about more unreliable works OK but your stripboard layout is very unreliable.

Sounds like a problem with the stripboard layout, not some problem with the 18M2.
 
I

inglewoodpete

Senior Member
If the hardware is unreliable at 32MHz with a large program, it will be just as unreliable with a short one. Generally, they should be more reliable at higher speeds with a good lower voltage supply due to the lower slew rates required. Edit: having now seen the chip's data sheet (ref post #17), the opposite is the case for the 18M2: lower voltage means lower maximum frequency.

Please post a couple of good quality top-and-bottom photos of the strip board.

Without seeing your hardware or software, I'd be looking for 100nF and 100uF capacitors mounted as close as possible to the PICAXE power pins (particularly the 100nF) and the 22k + 10k pulldown on the Serial In pin. Also, make sure you have good decoupling around all active components on the board.
 
Last edited:
D

DamonHD

Senior Member
OK, thanks, I'll poke around myself a little more and post photos if I cannot resolve this myself over the next few days. I'm fairly sure it's my lack of decoupling capacitors; even though the breadboard has fewer, I at least managed to more nearly star-wire its supply rails which may have saved me there.

Anyhow, I'm being reassured that the 32MHz and 3.3V supply combination is not of itself a problem: I wish the PICAXE datasheets were more like normal datasheets than advertising flyers! %^P

Thanks again!

Damon

PS. I do have the 22k+10k serial in pull-down in place.
 
S

srnet

Senior Member
A fuller description of what is meant by 'unreliable' would help.

The RFM22 is unusually sensitive to lay out issues and often on a breadboard its unstable, and it gets worse if you drive it faster. Nor is it as simple as fitting a few decoupling capacitors. Its the RFM22 that has problems, not the PICAXE.

18M2 is an odd choice for driving the RFM22, the 20X2 has hardware SPI and will drive it a lot faster without raising the clock rate.

And do not put the program in a polling loop just waiting for the ipksent flag to be set, there needs to be a timeout in the poll, to prevent the program locking up.

You need to post the circuit and photos of the board.
 
D

DamonHD

Senior Member
Well, 18M2 is what I got started on after 08M2, and I understand now that some devices have h/w SPI support, but it was only after I started development that the need for SPI at all became apparent.

Anyway, very interesting to heat about the layout issues.

I have now put a limit on the polling loop, which is where the problems were happening, so that the system can recover.

Here is the circuit with a reasonably recent PDF snapshot:

https://sourceforge.net/p/opentrv/code-0/491/tree/trunk/PICAXE/DHD201302L0/hardware/

Photos to follow if I don't manage to debug this myself quickly!

Rgds

Damon
 
S

srnet

Senior Member
Why doe the circuit need to be driven at high speed anyway ?

4Mhz or 8Mhz ought to be plenty.
 
D

DamonHD

Senior Member
Hi,

Because timing is pretty important (I will ultimately have to stay in sync with a receiver with a 1% duty cycle) I need to keep all major operations well under 1s, and generating the bit pattern to control an FHT8V and load it into the RFM22 FIFO (lots of bit twiddling and then >40 bytes of data) was taking about 1s all told, so souping up the clock was the easiest way out of that bind.

I have optimised the code paths, unrolled some loops, etc, etc, but in BASIC I am pushing my luck, obviously!

(I will be building a parallel stack on Arduino in C which will likely be far less trouble from a timing point of view, but I'm determined to see this version through, warts and all, since one particularly attractive feature of the 18M2+, and DS1306 is the ability to run at 3.3V or 2.4V (2xAA rechargeables), though I need an alternative to the DS18B20 to track temperature for the latter).

For pretty-well everything else at this stage 4MHz is fine, and there's lots of nap-taking while waiting for the seconds to roll...

Rgds

Damon
 
D

DamonHD

Senior Member
By just running the TX part of the code at 4MHz the problem has gone away again. I refactored the code to make doing so slightly less hideous. (I had the ideas buzzing round my head all night!)

This is not totally satisfactory, but given the suggestion that it may be the RFM22B at fault, and with a longer-term view of using one of the PICAXEs with h/w SPI support, I may let sleeping dogs lie since I am running late on this part of the project.

However, I will put up photos shortly (I have just taken them), and for reference here is a snapshot of circuit diagram, PDF and the complete current .bas file:

https://sourceforge.net/p/opentrv/code-0/494/tree/trunk/PICAXE/DHD201302L0/hardware/snapshots/20130223-r493/

Rgds

Damon
 
S

srnet

Senior Member
Well for one, I would cut the power, your using 100mW, is that needed or even legal in the UK ?

Also, do not just initialise the RFM22 and forget about it, it has a habit of resetting itself due to the so called 'Smart Reset' circuit detecting power line glitches. Good layout and supply decoupling will reduce the problem as will using only the power you really need. I would check that the RFM22 has not reset itself after every transmission.
 
D

DamonHD

Senior Member
Hi,

The 100mW would explain the dead pigeons and circling Ofcom black helicopters. I'll turn it down a bit and recheck the data sheet!

Interesting thought on the RFM22 resetting itself. How would you (quickly) check in this instance if such a reset had happened so the config could be re-applied?

Rgds

Damon
 
S

srnet

Senior Member
DamonHD said:
Interesting thought on the RFM22 resetting itself. How would you (quickly) check in this instance if such a reset had happened so the config could be re-applied?
Click to expand...
There is a POR flag bit that should be set, but I found it more reliable to check if the 3 main frequency setting registers have changed away from their configured settings.

Which also serves another purpose, you can check that you are actually transmitting on the frequency you should be.

There are also circumstances where if there is enough RF power fed back into the circuit, the Si4432 (the microcontroller on the RFM22) has its brains scrambled completely, the registers go haywire. The only recovery is a shutdown of the device, so dont just ground the SDN pin, control it with a PICAXE pin so you can force a RFM22 reset.
 
D

DamonHD

Senior Member
Thanks for that: if I see any evidence of brain-scrambling then I may well rejig the design as you suggest!

I've turned the transmit power down already which should reduce the chance of any brain-scrambling (mine or the microcrontroller's):

EEPROM ($6d,%00001011) ; RFM22REG_TX_POWER: Somewhat above minimum TX power.

Thanks again for all your help. As I'm sure you well know, struggling on one's own is a nightmare!

Rgds

Damon
 
D

Dippy

Moderator
In addition to the good advice above you should be aware that PICs have a voltage vs clock-frequency performance curve.
It may , or may not, be relevant here as I haven't checked in depth but just keep it in mind for the future.
 
D

DamonHD

Senior Member
That is definitely one of my concerns, thus the title mentioning the 3.3V supply, especially as I wish to run variants of this down to 2V (flat-ish 2xAA NiMH) in due course.

Which PIC is the 18M2+ derived from, please, so that I can go and look at its data sheet for exactly that curve?

Rgds

Damon
 
D

DamonHD

Senior Member
Fab, thanks!

Is there a clever way in software of telling approximately what supply voltage I'm running at? Given all the internal references and ADCs etc there probably is, but in any case I should probably make sure when I'm done that I can manage on 16MHz rather than winging it at run-time?

Rgds

Damon
 
N

nick12ab

Senior Member
DamonHD said:
Is there a clever way in software of telling approximately what supply voltage I'm running at? Given all the internal references and ADCs etc there probably is, but in any case I should probably make sure when I'm done that I can manage on 16MHz rather than winging it at run-time?
Click to expand...
Yes - the calibadc commmand can be used to approximate the supply voltage.
 
D

Dippy

Moderator
And, on those occasions where this can't be done you can use an external reference to achieve the same results.
When people want good ADC results (or where the expected ADCVin is known to be much lower than Vdd) they often use one of these methods.
 
D

DamonHD

Senior Member
Fab again! What a fount of knowledge you folks are!

I really only want a very rough "am I below 2.5V" kinda estimate without any extra external hardware, so other than being confused by a very fresh set of AAs, I can measure this very infrequently, and indeed complain when the batteries are getting low!

Rgds

Damon
 
D

Dippy

Moderator
If your PICAXE Vdd is from an unregulated supply (e.g. direct from batteries) you really should use a reference.
If you use straight ReadADC it will use the battery supply as the reference which will, as you know, droop.
This will distort your ADC values.
Have a look to see if this may upset your plans.
 
D

DamonHD

Senior Member
The only ADC measurement I'm currently doing is of an LDR/resistor potential divider tied to V+, so should be largely insulated from the absolute value of V+. There's nothing precision about what I'm doing: measure with a 10-bit ADC, mark with chalk, cut with a PICAXE... %-P

Rgds

Damon
 
G

Goeytex

Senior Member
If the Picaxe and RF module use the same supply then why not read the battery voltage via the RFM22B battery voltage register? Enable the Battery Detector in Register $07. Then read register $1B. No extra hardware needed.
 
S

srnet

Senior Member
Number one tip if your using the RFM22, read the data sheet, all of it, each and every page.

Then study the register set, all of them.

For instance there is a register in there that is somewhat easier to use than testing for ipxsent bit, you wont find it unless you search for it.
 
S

srnet

Senior Member
I would suggest the following revisions to the strip board layout.

1. Turn the RFM22 through 180degrees, so the antenna is at the end, the layout you have is doing a nice job of coupling the RF back into the power supply and signal wires, which will act as antennas

2. Fit a SMA socket for the antenna and keep the wiring to it short.

3. Ensure all the RFM22 ground connections are actually connected.

4. Put the regulator as close as possible to the RFM22 power pins, currently its at the opposite end of the board with a set of antennas connecting it to the RFM22.

5. Fit a 0.1uf or 1uF ceramic capacitor as close as possible to the RFM22 power pins, adding a 150pf NPO ceramic would be a good idea too.

6. Fit a minimum of 47uF Electrolytic capacitor, low ESR type, as close to the RFM22 power pins as you can get it.

7. Keep sensor wiring away from the RFM22, looks like you have a sensor with wires that actually go past the RFM22 and antenna.

8. And far better than stripboard would be a PCB with a ground plane.

9. Tune the antenna for best performance, if the antenna is mismatched, then RF power is going back into the RFM22.

10. Since you have a SMA socket on the PCB, you can fit the entire assembly in an alluminum screening box, with the antenna on the outside.
 
D

DamonHD

Senior Member
More top tips, thanks!

1) Yes, I do have the HopeRF documents.

2) On the next item I build I will take some of these suggestions on board, indeed.

3) On the eventual PCB, assuming the design is good enough to lay out and build multiples of, then I can take more of these suggestions to heart and have much better RF layout around the RFM22 of course.

Rgds

Damon
 
I

inglewoodpete

Senior Member
I downloaded your code. The 'Gosub' constraint appears to be 100. Since it's not a binary boundary, I have to assume it's a limitation of the PE, not the PICAXE itself.

I rarely use the M2 series of chips. I can see their limitations when you start writing large programs. SPIOut/ShiftOut and bit manipulation are obvious limitations. My preferred 'small' PICAXE is the 20X2.

I think you mentioned rebuilding your project. That might be a good time to consider the 20X2. On the other hand, if you have it working on an 18M2 already....
 
S

srnet

Senior Member
inglewoodpete said:
On the other hand, if you have it working on an 18M2 already....
Click to expand...
But only just.

I see no reason why polling the packet sent flag would only work at 4MHz, and no faster.

The RFM22 will work reliably with the mucxh faster hardware SPI commands, in SPI fast mode and at 16Mhz. That there appears to be a problem at 8Mhz with the much slower Shiftout commmands suggests something is marginal, and could well fail in some circumstances at 4Mhz also.
 
D

DamonHD

Senior Member
@ip: There's very definitely a limit of 256 gosubs in some PICAXEs (and 16 in older ones) to the best of my understanding! Are you saying that you could see that I was using 100? If so, how (other than using an editor to count them)?

@s: The project is basically working find on 18M2 now (this evening is a plausible completion time for the bulk of the original objectives, after several weeks of work, for example, and currently seems reliable). I will definitely look at one of the parts with hardware SPI support, and doing some better layout and decoupling on any revision (though have now bought 10x 18M2+ so have a small incentive to make this all work).

BTW, I've just revised the circuit again with (a) more decoupling for the RFM22 and (b) notes about layout reflecting your excellent advice. All good stuff: keep it coming!

Rgds

Damon
 
Last edited:
D

DamonHD

Senior Member
The issue is that its a constraint that I've never had to deal with before on any language or platform and I have no real way of telling how close I am. That's the sort of constraint that I don't want to be blown out of the water by at the last minute!

Rgds

Damob
 
Buzby

Buzby

Senior Member
Code:
The constraint comes from the architecture used in the PICAXE firmware, but as Dippy says, 255 is usually *plenty* enough.

Think about what 255 subroutines in a memory of 4096 bytes would look like.
On average, each subroutine would be less than 16 bytes long.
That's about this much code :
Code: 
Routine_1:
  b0 = b1 + b2
  b3 = b4 + b5
Return
It would be a very unusual program that needed so many tiny subroutines.

Are you sure your code needs so many ?
 
D

DamonHD

Senior Member
I'm not sure, but indeed I was thinking along the lines that you are, and it does seem as if it might be difficult to run out on an 18M2+! I do have quite a few small routines, but not many that small for example. So I can probably stop worrying about it. Except that gosub chaining may be a useful compactness/performance improvement anyway in a few critical routines...

Rgds

Damon
 
S

srnet

Senior Member
DamonHD said:
Except that gosub chaining may be a useful compactness/performance improvement anyway in a few critical routines...
Click to expand...
Other way around, if you want to improve performance (speed) reduce the number of gosub and returns it takes to carry out a specific function.

One other thing, the polling of the packet sent flag on the RFM22 by reading the register is a very slow way of doing it. You have set the interrupt, so connect the NIRQ pin to a PICAXE pin and test for packet sent with;

do
loop until NIRQ = 0 'loop until a packet is flagged as sent.
 
D

DamonHD

Senior Member
Hi again,

I do selectively inline performance-critical things, but sometimes I don't want to do that across module boundaries, etc.

All the times I'm waiting for an 'interrupt' I'm typically going to be waiting 10s of milliseconds, so I don't want to give up an I/O pin for it (yet), and I'll have to read the status registers anyway to clear interrupts and/or see what happened. So I don't see busy waiting as gaining my much at when I can be doing a "nap 0" and saving the odd erg... What have I overlooked?

Rgds

Damon
 
I

inglewoodpete

Senior Member
DamonHD said:
@ip: There's very definitely a limit of 256 gosubs in some PICAXEs (and 16 in older ones) to the best of my understanding! Are you saying that you could see that I was using 100? If so, how (other than using an editor to count them)?
Click to expand...
I counted them using the PE's "find" command.

Considering the code you have posted for your other thread: it is very sophisticated but not really tailored for a finite resource like a PICAXE. I personally find it hard to follow, although I can see that you're not a beginner by any means. I started programming PICAXEs with the 08M, with 256 bytes of program space and limited functionality on each pin. I had to forget about the mainframe and PC programming I do in my other life. Sure, I can take what I have learned from programming (almost infinitely) bigger systems but the limited hardware & memory exerts a large influence on the format and style of the PICAXE software I write. Also, you will find that the hardware and software are best developed together.
 
You must log in or register to reply here.
Top