In Slvu195, it is mentioned about the TPS2384 PoE firmware. How can I download the firmware? Could you give me a Web link? Thanks!
This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
In Slvu195, it is mentioned about the TPS2384 PoE firmware. How can I download the firmware? Could you give me a Web link? Thanks!
I will contact you via email about this.
Hi Eric. I am working with a TPS2384 and am interested in find out out the FW rev to be used with the component. We have various versions from 15 up through 26 (decimal). Since those are a few years old, is there a later version that is recommended to be used?
We had been using version 23, but it seems to be very slow on device discovery and was markedly slower than version 15. Version 26 seems to be much better.
Appreciate your input!
Thanks...Rick
I am not familiar with the firmware rev #'s you are referencing. Can you describe where these rev #'s come from?
I am not quite sure of the history of the rev numbers. We use the TPS2384 in a network switch that has PoE control. The code that is loaded into the box was supplied in some files. Recently I got involved due to a fw issue that we had with PoE devices not coming up in a timely fashion. In digging further, we came across a number of FW files and a readme:
-----------------------------------------------------------------------------------------------------------------------------------
- disabled port UV/OV fault mechanism.
Released version 20
- changed speed of I2C bus 0 to be the same as I2C busses 1 and 2; added NOPs to commensate for the constant generator.
Released version 21
- changed comments in include.h; fault delays are approx. 40 seconds, not 10 seconds.
- changed comments in main.c; the timer interrupts are 1.5mSec and 520uSec.
- changed delay before (AC Disconnect) reset to match comment (of 15mSec). The delay had been 5mSec.
- changed power management logic to insure that a port enabled for power-up is infact powered before a second port is considered for power-up.
There was a bug that the system power consumption was incorrect when ports were very slow to power, and so more ports would be enabled than
what could be supported.
- changed the #include structure so that the code version information (modes.h) was only included by those files that needed it (rather than all files).
Released version 22
- corrected a bug in the power manager which would cause ports at the same priority to flip/flop when a lower-priority port was present.
Released version 23
- Built a special version of the code for Sifos Technologies which decreased all fault delays (including disconnect) from approx. 41 seconds to
approx. 1 second. The long disconnect delays were preventing Sifos from testing the system efficiently. The Sifos delays can be disabled by
commenting-out "#define SIFOS_TESTS" in include.h.
Released version 24
----------------------------------------------------------------------------------------------------------------------------
We have a couple of revs beyond the release note (25, 26).
I am not sure where the FW files came from, so am looking to see if they came from TI. The files are text files which look like S format files with address and data information. Here's a partial snapshot of one of the files:
@4000
31 40 00 0A B0 12 B8 47 0C 93 08 24 3C 40 00 02
0E 43 30 12 F9 06 B0 12 52 7E 21 53 B0 12 BC 6F
B0 12 4E 7E 30 40 28 40 FF 3F 04 43 36 40 00 02
35 40 D6 03 B6 40 A5 5A 00 00 26 53 15 83 FA 23
30 41 06 12 0A 12 08 12 08 43 4C 5C 46 4C B0 12
The unfortunate part is this is for an older product and many of the principal players in the product development are no longer here. So it makes it difficult to track down what may have transpired.
So is this something that would have come from TI?
Thanks...Rick
I will see what I can track down. Can you confirm which TI PSE controller is being used here (TPS2384 or TPS2383 maybe?).
I was looking further at the code support routines and it looks like it loads the code into the MSP430, so it is likely code for that for controlling the TPS2384. Hopefully that helps???
Yes, I agree. I opened up a recent MSP430 programming file that I had and it had the @4000 at the top as well. Which MSP430 is in your system? I believe we only have target programming files for MSP430F148 and MSP430F169.
It may help to know that the special code for the CPU was to control the 2384 was developed for the Nortel products (now part of Avaya). Not sure how that was managed, but maybe that will help to move the process along.
Thanks...Rick
Release 2.4 firmware is the latest.
Please provide more detail about the DC MPS test setup, procedure, equipment used, and environment.