|
Hi, Why can't the flash utility sync up faster than 38.4 kbps even you can select 57.6 and 115.2 kbps within the utility? I tried it on an LPC2214 as well as an LPC2129, both with 12MHz xtals. Thanks Jane |
|
|
Philips Flash Utility V2.2.0 (max baud rate = 38400???)
Started by ●January 8, 2005
Reply by ●January 8, 20052005-01-08
|
At 06:11 PM 1/8/05 +0000, you wrote: >Why can't the flash utility sync up faster than 38.4 kbps even you can >select 57.6 and 115.2 kbps within the utility? What are you using for the level conversion interface? Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
|
|
Reply by ●January 8, 20052005-01-08
|
--- In , Robert Adsett <subscriptions@a...> wrote: > At 06:11 PM 1/8/05 +0000, you wrote: > >Why can't the flash utility sync up faster than 38.4 kbps even you can > >select 57.6 and 115.2 kbps within the utility? > > What are you using for the level conversion interface? > > Robert > > " 'Freedom' has no meaning of itself. There are always restrictions, > be they legal, genetic, or physical. If you don't believe me, try to > chew a radio signal. " > > Kelvin Throop, III Hi Kelvin We're using a standard MAXIM RS232 chip. The interface is a known working 115.2 kbps capable interface. I was wondering whether it is bootloader firmware version dependant? I take it you have had no problems running at 115.k? It's strange that 9600 and 38400 work fine. Jane |
|
|
Reply by ●January 8, 20052005-01-08
|
At 06:25 PM 1/8/05 +0000, you wrote: >Hi Kelvin It's Robert actually, Kelvin is fictional ;) >We're using a standard MAXIM RS232 chip. The interface is a known >working 115.2 kbps capable interface. I was wondering whether it is >bootloader firmware version dependant? I take it you have had no >problems running at 115.k? It's strange that 9600 and 38400 work fine. After I sent it another neuron went off and I checked the User manual. The possible baud rates depend on the crystal frequency. For the 2106 User manual it's in table 145 on page 185. I expect the MAX is fine but some level translators have fairly low bandwidths (I've seen specs as low as 9600 bd but I don't remember the part that was for). Reviewing the User manual I expect you've just hit the limit but you might also want to review the data sheet for the MAXIM part. Myself, I've not felt the need to try programming above 38400. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
|
|
Reply by ●January 8, 20052005-01-08
|
--- In , Robert Adsett <subscriptions@a...> wrote: > At 06:25 PM 1/8/05 +0000, you wrote: > >Hi Kelvin > > It's Robert actually, Kelvin is fictional ;) > >We're using a standard MAXIM RS232 chip. The interface is a known > >working 115.2 kbps capable interface. I was wondering whether it is > >bootloader firmware version dependant? I take it you have had no > >problems running at 115.k? It's strange that 9600 and 38400 work fine. > > After I sent it another neuron went off and I checked the User manual. The > possible baud rates depend on the crystal frequency. For the 2106 User > manual it's in table 145 on page 185. I expect the MAX is fine but some > level translators have fairly low bandwidths (I've seen specs as low as > 9600 bd but I don't remember the part that was for). Reviewing the User > manual I expect you've just hit the limit but you might also want to review > the data sheet for the MAXIM part. > > Myself, I've not felt the need to try programming above 38400. > > Robert > " 'Freedom' has no meaning of itself. There are always restrictions, > be they legal, genetic, or physical. If you don't believe me, try to > chew a radio signal. " > > Kelvin Throop, III Thanks Robert I'll have read of the RS232 data sheets and the 2106 user manual. On the subject of feeling the need to try to program above 38400...we've got >200K of Thumb code and thousands of chips to ISP in the future...I know it will make a difference to our to our PCB subcontractor. Cheers Jane |
|
|
Reply by ●January 8, 20052005-01-08
|
At 06:48 PM 1/8/05 +0000, you wrote: >On the subject of feeling the need to try to program above >38400...we've got >200K of Thumb code and thousands of chips to ISP in >the future...I know it will make a difference to our to our PCB >subcontractor. Yep for high volume it will make a big difference. It might be worth your while to bootstrap to a higher baud rate. It's something I've been meaning to work on when I get some time. The idea is the initial ISP would download a a small download program to RAM and run it. It would then set the serial port to a higher baud rate and use a binary download protocol. The higher might get you a factor of 3 (if you can match rates closely enough), the reduced overhead of the binary protocol would get you a factor of 2. All this minus the actual programming overhead and the time to download the initial stub. Another option in volume might be to get the parts preprogrammed (assuming they run identical programs). That gets it out of your subcontractors way entirely. For a lot of the stuff I've done functional testing made the programming time disappear into the noise. Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
|
|
Reply by ●January 8, 20052005-01-08
|
--- In , Robert Adsett <subscriptions@a...> wrote: > At 06:48 PM 1/8/05 +0000, you wrote: > >On the subject of feeling the need to try to program above > >38400...we've got >200K of Thumb code and thousands of chips to ISP in > >the future...I know it will make a difference to our to our PCB > >subcontractor. > > Yep for high volume it will make a big difference. It might be worth your > while to bootstrap to a higher baud rate. It's something I've been meaning > to work on when I get some time. The idea is the initial ISP would > download a a small download program to RAM and run it. It would then set > the serial port to a higher baud rate and use a binary download > protocol. The higher might get you a factor of 3 (if you can match rates > closely enough), the reduced overhead of the binary protocol would get you > a factor of 2. All this minus the actual programming overhead and the time > to download the initial stub. > > Another option in volume might be to get the parts preprogrammed (assuming > they run identical programs). That gets it out of your subcontractors way > entirely. > > For a lot of the stuff I've done functional testing made the programming > time disappear into the noise. > > Robert > > " 'Freedom' has no meaning of itself. There are always restrictions, > be they legal, genetic, or physical. If you don't believe me, try to > chew a radio signal. " > > Kelvin Throop, III Thanks Robert. I'll take a look next week on the actual data quality being received transmitted at the CPU. I agree with you, from the table in the user manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at 12MHz even though we'll probably have a small percentage error per bit, we should still be OK. Jane |
|
|
Reply by ●January 8, 20052005-01-08
|
At 07:15 PM 1/8/05 +0000, you wrote: >I'll take a look next week on the actual data quality being received >transmitted at the CPU. I agree with you, from the table in the user >manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at >12MHz even though we'll probably have a small percentage error per >bit, we should still be OK. I think one of us is reading the wrong line. I see 12.288 MHz topping out at 38400. What is missing is a description of what is limiting the match so that it could be determined for the actual crystal used. I expect it's a divisor issue. If we knew what it was it should be straightforward to figure out which baudrates will match (and maybe even switch crystals to meet multiple neeeds). Robert " 'Freedom' has no meaning of itself. There are always restrictions, be they legal, genetic, or physical. If you don't believe me, try to chew a radio signal. " Kelvin Throop, III |
|
|
Reply by ●January 8, 20052005-01-08
|
I had issues with 115K until I replaced the Xtal with a 14.7456MHz one. Also, the lpc21isp.c from Martin Maurer is much more reliable. Big plus using it you can customize, even to the extent of automatically updating the bootlodaer if you wish. --- In , Robert Adsett <subscriptions@a...> wrote: > At 07:15 PM 1/8/05 +0000, you wrote: > >I'll take a look next week on the actual data quality being received > >transmitted at the CPU. I agree with you, from the table in the user > >manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at > >12MHz even though we'll probably have a small percentage error per > >bit, we should still be OK. > > I think one of us is reading the wrong line. I see 12.288 MHz topping out > at 38400. > > What is missing is a description of what is limiting the match so that it > could be determined for the actual crystal used. I expect it's a divisor > issue. > > If we knew what it was it should be straightforward to figure out which > baudrates will match (and maybe even switch crystals to meet multiple neeeds). > > Robert > " 'Freedom' has no meaning of itself. There are always restrictions, > be they legal, genetic, or physical. If you don't believe me, try to > chew a radio signal. " > > Kelvin Throop, III |
|
|
Reply by ●January 9, 20052005-01-09
|
--- In , Robert Adsett <subscriptions@a...> wrote: > At 07:15 PM 1/8/05 +0000, you wrote: > >I'll take a look next week on the actual data quality being received > >transmitted at the CPU. I agree with you, from the table in the user > >manual for the LPC2106 you can run at 115200 at 12.288 MHz, so at > >12MHz even though we'll probably have a small percentage error per > >bit, we should still be OK. > > I think one of us is reading the wrong line. I see 12.288 MHz topping out > at 38400. > > What is missing is a description of what is limiting the match so that it > could be determined for the actual crystal used. I expect it's a divisor > issue. > I've had the UARTs on the LPC21xx LPC22xx running fine at 115.2k (e.g. receiving large files with 32 bit CRCs). It just that the divisor arrangement means the baud rate @ 12MHz is approx 1% out (with the PLL multiplying the XTAL by 5 to 60MHz / VPBDIV = 1). I just wondered whether the bootloader on the chip gives up if it can't get an exact baud rate... Jane > If we knew what it was it should be straightforward to figure out which > baudrates will match (and maybe even switch crystals to meet multiple neeeds). > > Robert > " 'Freedom' has no meaning of itself. There are always restrictions, > be they legal, genetic, or physical. If you don't believe me, try to > chew a radio signal. " > > Kelvin Throop, III |
|
|
