SEROUT 6,T4800_16("U") = 0x00 0xD5????

[jmumby]

28x1 16Mhz resonator, Picaxe proto board (no output driver chip). 3.3V

SETFREQ EM16
'CALIBFREQ -5
START:
SEROUT 6,t4800_16,(0x55)
'GOTO START

When I use the above code I get 0x00 and 0xD5. Immediately after download I get a "U" but not if I reset or power down and back up again. if I set calibfreq (even with a resonator) I get 0x00 0x55. If I loop it I get 0x00,0xD5,0x55,0x55,0x55,0x55,0x55,0x55.

Removed resonator and set freq m4 but same result.

Regards,

Frustrated

 

[moxhamj]

How frustrating. I just had a 14M tell me it wouldn't even accept Serout as an instruction due to firmware incompatability. But swapping to another chip I bought a few months later worked fine. Serves me right for being one of the first people in Australia to buy a 14M!

Not that this helps jmumby very much, except to highlight that there are still occasional bugs in the firmware. Might have to handball this over to Technical...

 

[BCJKiwi]

Part of the problem may well be the 3.3V at 16MHz.

The 28X1 requires a minimum of 4.5V to start and run properly at 16MHz.

I found that once it was started at 16MHz, the supply could drop to around 3.5V and it would keep running, but with less than 4.5V it usually would not start at 16Mhz but at 4MHz!

See here http://www.picaxeforum.co.uk/showthread.php?t=8609

 

[hippy]

It's ultimately down to using T4800. This requires the serial line to be high at idle, active low. After reset the output pin will be set low, active-high, this will appear to the receiver as having sent the start bit of a character ($00). When the SEROUT executes, it reconfigures the output but depending on when that occurs the receiver may already think it is receiving a character and thus mis-read the first sent.

Ideally, always use Nxxxx baud rates.

To resolve the problem here, use a "HIGH 6 : PAUSE 10" at the start of the program. That might not erradicate all $00's received but should prevent corruption ( ignoring the issues about 28X1 baud rate inaccuracies ).

 

[womai]

I had plenty of headache with trying to run the 28X1 at 16 MHz with only 3.3V. I have an existing design (a time domain reflectometer) that uses a 28X and works just fine and is extremely reliable. I know that 3.3V at that speed is outside spec for the 28X1, but the low supply voltage is necessary to be compatible with the 3.3V high-speed PECL devices the design uses. When I tried to substitute a 28X1 for the 28X every other time I tried to write to the internal EEPROM it would write garbage, and also the serial connection would sometimes get corrupted (I didn't debug this too far but it seemed like sometimes characters were dropped). I tried with 3 different 28X1 devices, but every time the same result. Yes I do have proper power decoupling - lots of 10uF, 1uF, 0.1uF and 0.01uF capacitors across the board (this is >2 GHz design so I have to be careful). I also tried slowing it down to 4 MHz and even 1 MHz when writing to the EEPROM but no luck.

Now I even designed a daughter card that carries a 28X1, runs at 5V, but translates all the levels between 3.3V and 5V. I expected this to work, but same issue - unreliable sertxd/serrxd, and problems with writing to the EEPROM.

Looks like I'll have to stick with the 28X for this project, which is a pity because I could really need the 20 MHz and the hserout to speed up operation.

Wolfgang

 

[jmumby]

Unfortunately I get the same result with 5v or 3.3v. Im trying to write to a microSD with the infamous uDrive. There is a reset pin on the device so for now I am pulling that down sending out anything to "initialize" the serial. Which works.

 

[hippy]

So to summarise, it looks like three potential problems identified here -

Using 16MHz at 3V3
Using T4800 not N4800
No access to CALIBFREQ to tweak baud rate if using external crystal

Not sure what womai's problem is regarding writing to internal Eeprom at 5V. That should work. I don't recall any similar problems having been mentioned before for the 28X1.

 

[jmumby]

I have convinced myself that high at idle is causing the 0x00 before sending as every byte after that is fine. I would have thought a pull up resistor would have sorted that, but I am a n00b. Jury is out on the voltage being an issue. If I have the uDrive off (it must have no command sent at all other than "U" to initialize) then turn it on via an output and send a "U" I don't have a problem. I hope to have the uDrive functioning this weekend so I will know more then. Here's me thinking the wifi and GPS were going to be the tricky ones.