MAX3100 Uart problems

Hi All,

Anyone else using the MAX3100 SPI UART ?

We seem to have a problem with some devices starting up at the default baud rate ( divisor 0 ) instead of the commanded baud rate ( divisor &hC0 ). Worse, it seems to be temperature related. Devices which start and accept the config command ok at room temp, refuse to start ok at 60 deg C.

Anyone else using these at this sort of temp range ?

--
Regards,

Adrian Jansen           adrianjansen at internode dot on dot net
 Click to see the full signature
Reply to
Adrian Jansen
Loading thread data ...

The chips can be a pain. There are a couple of 'oddities' that may be catching you. The code given in the data sheet as an 'example', won't actually work to send data, unless some data is received. Great example... The internal oscillator, can be _very_ slow to start at higher temperatures. It is also fussy on crystals. I am now running the units using an external oscillator, and they are much more reliable like this. The SPI communications, seem to get a bit borderline at higher temperatures. Though the signal feeding the clock/data, were 'in spec' for their voltage levels, I found raising the 'high' level fractionally (with a pull up resistor), was necessary to ensure reliable operation.

Best Wishes

Reply to
Roger Hamlett

Also consider the NXP(Philips) SPI/ I2C to UARTS

SC16IS740, 50, 52 Dual UARTs.

Joe

Reply to
Joe G (Home)

Thanks Roger.

We have around 100 of these in service now, and this only cropped up in a very small number, as usual, well after the initial product testing.

I too struggled with the code examples, and finally found how to get the beast to work. Yes they are tricky, but having got the details right, they seem to work fine on the uart side.

I use external oscillator, from the processor crystal at 3.6864 MHz.

Interesting about the SPI, but its really wierd that when transmitting the 16 bits of config data, at least the first 12 must work, to set the Rx and Tx enabled, and only the last 4 bits, which define the baud rate, get lost. I checked the SPI clock and data lines, and I am getting +5 volt rail-to-rail swings. Also the actual data transmission seems to be rock-solid. I never get garbage, or dropped characters. Either they start up and transmit correctly at the 4800 baud rate, or at the default

230 Kbaud rate. To me, that seems to prove that both the Uart system, and the SPI are working correctly. One unit I have switches abruptly from always correct startup below 55 degC to always incorrect ( 230 Kbaud ) at 60 degC.

Even odder is that these are in a device where the processor configs the UART during the boot phase, then switches out of the bootloader and into the main program, and that configs the uart again ( at the same baud rate ). And that config is the one that is wrong. But a second repeated config in the main program always gets the values correct. I found this out yesterday while playing around reading back the config, to see what was going on. I still dont know for sure what the first config in the booloader does at the high temp, but I will find out...

--
Regards,

Adrian Jansen           adrianjansen at internode dot on dot net
 Click to see the full signature
Reply to
Adrian Jansen

I once used these on a project and had similar problems. I measured a lot of noise right back at the Vcc pin and fixed it with a LC filter, perhaps that is causing you problems too?

Regards

AJ

Reply to
AJ

It sounds as if there is an internal gate, into the BRG, which changes behaviour at high temperature. Try the silliness, of adding pull-ups to the SPI on one of the problem units, and test again. You obviously have a potential software fix, by reading back the configuration, and looping if it is not right. I too had no problems with the comms, but had oddities in configuration. The resistors fixed it, and it was still at prototype, so these were incorporated into the board.

Best Wishes

Reply to
Roger Hamlett

Thanks for the suggestion. I scoped the supply and data lines. Vcc is stable with no more than 10mv ripple. All the SPI lines pull within 50 mv of ground and supply, with no visible overshoot or anything on the edges, in fact they are cleaner than almost any other digital signals I have seen. Even if pullups fixed the problem, it means a board redesign, and I would always have doubts over whether we fixed the real problem.

I have two more units on the bench, both these fail at around 48 degC. But two different modes. One just totally refuses to config above 48, so Tx never gets turned on. I doubt it receives any SPI commands at all, but its hard to prove. The other accepts the config, but the baud rate bits get lost, so it starts at 230 Kbaud. And it will not accept the correct baud rate even in a loop repeating the config. The really odd thing is that both these units will start correctly below 48, then continue to work, transmitting data perfectly, while I raise the temp to at least 65. So the SPI works perfectly in data mode, just never in config mode above 48.

We talked about 100% testing the units at 60-70 degC, but it adds significantly to the production cost and cycle time.

Our solution is to scrap these MAX3100 parts totally, and replace the processor with one having dual UARTS. Fortunately this is a relatively easy fix, and likely to be much more certain than any other fooling around.

--
Regards,

Adrian Jansen           adrianjansen at internode dot on dot net
 Click to see the full signature
Reply to
Adrian Jansen

Dumb question, Adrian, but still needs asking - have you asked Maxim about this? We had a weirdo problem with one of their chips and their tech support response to an email enquiry was slow (5-7 days) but impressive.

Reply to
budgie

this?

No, I havent. I might still do that, but since we decided to drop the chips, it seems hardly worth it.

--
Regards,

Adrian Jansen           adrianjansen at internode dot on dot net
 Click to see the full signature
Reply to
Adrian Jansen

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.