Author Topic: Problem programming 89V51RC2.  (Read 7385 times)

pmax65

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
    • Email
Problem programming 89V51RC2.
« on: May 18, 2007, 02:39:55 am »
Hi there,
I used Flash Magic with success with my own circuitry based on the 89C51RC2 having no problems.
Now I tried to use it with the 89v51RC from MXP, and I'm not able to communicate with it.
Whether I place one 89C51RC2 on the same board it works right, so I suppose the board is working fine.
I looked to the RXD, TXD and RST signal during the Flash Magic communication initialization procedure, and I can see a very well shaped 200ms reset signal, followed after 300ms by the "U" character on the RXD, but no response on the TXD line.
Therefore, I programmed the device using the parallel programmer with my user code, and looking to some signals quickly asserted after reset, I established that the MPU enters the user code just 160ms after the RST line is released.
Does anybody have suggestions about this?
Massimo


pmax65

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
    • Email
Re: Problem programming 89V51RC2.
« Reply #1 on: May 18, 2007, 02:48:36 am »
Hoops!
I missed to tell you that my own board switches the PSEN to GND and P2.7 to VDD, when Falsh Magic asserts the RTS line.
Massimo
 

pmax65

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
    • Email
Re: Problem programming 89V51RC2.
« Reply #2 on: May 18, 2007, 03:45:30 am »
Just fixed it!
I reduced T2 to 100ms and it works ok.
Now the question is: why the 89V51RC2 starts the user firmware so quickly?
NXP stated that it should delay 400ms @ 12MHz (see NXP app.note TN06007.pdf), and my own board clock is just 12MHz.
Massimo

Jan Waclawek

  • Full Member
  • ***
  • Posts: 220
    • View Profile
    • EFTON homepage
Re: Problem programming 89V51RC2.
« Reply #3 on: May 18, 2007, 08:17:57 am »
Now the question is: why the 89V51RC2 starts the user firmware so quickly?
NXP stated that it should delay 400ms @ 12MHz (see NXP app.note TN06007.pdf), and my own board clock is just 12MHz.
Well, I have no idea where they got the 400ms from, and I am afraid neither does NXP...
The bootloader timeout is given simply by loading #0fbh into WDTD, and starting the watchdog. Please calculate the timeout yourself...

JW

Andy Ayre

  • ESAcademy Staff
  • Sr. Member
  • *****
  • Posts: 2172
    • View Profile
    • Embedded Systems Academy, Inc.
    • Email
Re: Problem programming 89V51RC2.
« Reply #4 on: May 18, 2007, 08:48:37 am »
The 400ms should be the maximum watchdog timeout period at 11.0592MHz. Does it not work out to that value?

Andy
Embedded Systems Academy, Inc.
support at esacademy dot com

Jan Waclawek

  • Full Member
  • ***
  • Posts: 220
    • View Profile
    • EFTON homepage
Re: Problem programming 89V51RC2.
« Reply #5 on: May 18, 2007, 11:27:18 am »
Well..... you know..... No. :-)

As per datasheet, the watchdog counter is incremented once each 334064 clocks (AFAIR the datasheet* explicitly states XTAL1, so no confusion can arise whether this is x2 or not). If the watchdog counter (WDTD) is set initially to FB (and it is - you can check it yourself), it  rolls over after 5 increments and that's the point where it resets.
Now the calculation in the datasheet says slightly less - 334064 * (0xFF - WDTD) - but that's IMHO just the "safest minimum"- the 334064 divider apparently may start up at a random value... But, all in all, being it 4 or 5 "cycles", it's still in the 100-150ms range, which is further than 400ms...

If I am allowed a guess, the 400ms came from some sort of error or maybe a different specs than the final one. For example, if you start from a maximum clock of 33MHz (which was the maximum clock of the SST's predecessors of this chip), the 33something divisor starts to make sense, the watchdog timeout is 10ms per one watchdog timer tick (and, indeed, the older SST chips had an independent internal oscillator for the watchdog, ticking approx. once in 10 ms!). So, with the reload value of 0xFB and 33MHz, you get around 40ms, which with a small typo of making one extra zero yields you the datasheet value... OK this is pure speculation... Ask perhaps the insiders at NXP...


Jan Waclawek



---
* It certainly does, but I don't remember which one - the NXP/Philips, or the "original" SST - you certainly already know this line of me... :-)

pmax65

  • Jr. Member
  • **
  • Posts: 5
    • View Profile
    • Email
Re: Problem programming 89V51RC2.
« Reply #6 on: May 18, 2007, 01:53:58 pm »
The 400ms should be the maximum watchdog timeout period at 11.0592MHz. Does it not work out to that value?

Andy
Hi Andy,
first of all, thank you for the nice Flash Magic program. I'm a HAM radio and I use it for my home workshop applications. It's great.

No, it doesn't work with 400ms. First I started with T1=200ms and T2=300ms (the values used for the C51RC2) and the communication was over, then (after I took a look to the signals with the DSO) I reduced T2 to 100ms and it works great!
Massimo

Je Gold

  • Full Member
  • ***
  • Posts: 135
    • View Profile
Re: Problem programming 89V51RC2.
« Reply #7 on: May 27, 2007, 12:00:41 am »
please ensure you have the "latest" Flashmagic version.... some older version had a timing error between RESET on the DTR line and sending a 'U' character to the P89V51 to put it in to bootloader programming mode.

Joe