ADS1232Ref

Omar,

I'm only guessing about how you have this hooked up.  Are you saying that you have an external processor connected to the ADS1232REF?  Can you send a schematic or drawing of what you are trying to do?  DRDY/DOUT is an output on the ADS1232, so I'm confused about what you call DataReady.

If you are using external connections to other devices you may be having some kind of ESD issue that is halting the processor.  If you want to capture large blocks of data, a good way to do this is by using a terminal program like hyperterminal or terraterm.  You can communicate via USB and continuously stream data to the terminal program.  That data can be saved to a file.   Review the ADS1232REF user's guide for more information.

Best regards,

Bob B

Hi Bob,

Im talking about Data Ready from de TUSB3410VF because i need it in order to start the communication with the MCU.

Im trying to skip the TUSB because i want to communicate this card with and WinCE 6 device and i dont have drivers for this, so im trying to use UART directly instead of the TUSB3410VF.

I send the DataReady signal directly to the MCU using a digital output from an external MCU.

Thanks Bob for your answer,

Omar F.

Omar,

That clears things a bit.  How are you powering the components on the USB side and what position is the programming switch SW9? 

I think what you are trying to do is RESET the device from time to time.  This is a bad approach.  The TUSB3410 control signals are only meant to be used for the bootstrap loader for the MSP430.  If switch SW9 is in the USB position, this is meant to only program the device, and not to be used in normal operation.  You should not be trying to reset the ADS1232REF because you may be inadvertently entering the BSL mode.

I'm also assuming that you are using the power supply in the wrong mode as well, which means you are defeating the isolation devices used to prevent ESD events from locking up the processor.

So here is something to try.  Place SW9 in the JTAG position, and connect a USB cable to the board, even though you do not use the USB.  Just use it to provide power.  Then you should be able to use RX and TX as you have been.  Don't try to use the control signals.  You can stop and start the data using the ASCII characters. To start streaming  send 'sCRLF' and to halt use any character.  Normally I send just a 'CRLF'.  That is a better approach than using a system reset.

Best regards,

Bob B

Bob,

I was powering the usb with the 3.3V_USB terminal of the board, i tried the use the board like you said but i cant communicate with the board I send sCRLF that is 0D0A53 in hexadecimal and the board doesnt send me anything. If I used the boad in USB mode and I manually power on the Data Ready from the TUSB Im able to communicate with the board using the same command.

Thanks for the help

Omar

Omar,

You are resetting the MSP430 processor if you use the DTR line.  This is way outside of the scope of how this system is designed.  You need to stay within the confines of how the system works.  You cannot think of this in terms of normal RS232 type behaviour.  There is no handshaking taking place. Normal operation for this board is with the SW9 in the JTAG position. 

I really don't know how you were getting any data before, or if the data is even valid. When the system is reset, what comes out the TX pin is what is pictured in the user's guide in section 5.1 with the parameters as shown in that same section.  So the first line sent is the firmware version, the second line is a copyright statement and the third line is a prompt.  So every time you reset the micro, this message is sent.  No conversion data is ever sent until commanded.  Any command sent to the RX pin will be echoed back, so if you send 'sCRLF', that command will be echoed back.  If you don't see this data, or if it comes back different, then maybe you have your baud rate or some other setup incorrect.  So when you first start the system, what characters/character sequence are you getting?

The 'sCRLF' is represented as first character transmitted, first character processed.  Maybe that is what you mean by showing the total transimission as MSB first.  More than likely the TUSB3410 is interfering with the RX line, and that is why the command is not working.  You should cut the trace coming from the TUSB3410 for the RX pin.  The TX pin will not be an issue.

Best regards,

Bob B

Bob,

Im using the SW9 in JTAG with a 9v battery,when I turn on the board im getting this #NUL#CR#LF#CR#LF#CR#LFADS1232REF 1.1.0d (c)2005-2006 Texas Instruments#CR#LF1232>.

But i send sCRLF in I get and s echoe but i dont recieve any info of streaming data.

Omar F.

Bob

I cut this but i still cant communicate with the board.

Omar,

Obviously you are communicating to some degree or you wouldn't get the echo.  The echo should also send a CRLF after the s.  Do you see the CRLF echoed back? 

After reviewing the firmware code I see that you only need to transmit the CR character.  The code will interpret the CR as a CRLF, and that is what gets returned in the echo.

Have you tried any of the other commands, like 'qCR' for query the setup, or 'vCR' which should send the version info, or 'aCR' which should give the credits for the hardware/software?  Unlike the 's' command, these other commands should return a string of information followed by the '1232>' prompt.

If none of these other commands work, it may be possible that the CR may be missed.  Basically the UART receive buffer is only one character, so it is possible that the CR  character is getting lost.  You might want to try a small delay between the sending of the characters. 

Best regards,

Bob B

Bob,

Can you give me the code of de MCU so I can understand the communication?

Omar F.

Bob,

I was doing some test and now when I turn on my board it says NO DATA on the LCD.

Omar F.

Omar,

The firmware files are contained in a zip file on our ftp site:

ftp://ftp.ti.com/pub/data_acquisition/ADS123xREF/ADS123x_CDROM/Firmware/Firmware_Source_Code/

The code is a bit hard to follow as it uses freeRTOS.  That means there is task swapping going on.  What you will be most interested in seeing is Console.c and Uart.c.

If you are seeing NO DATA on the LCD, then the MSP430 is no longer communicating with the MSP430.  Is it possible you shorted something while you were testing?

Best regards,

Bob B

Bob,

Have you ever tried to communicate the board with another device using Tx and Rx holes on the board?

I just recieve but I cant send anything I cut the line betwen the Rx and the TUSB and still I cant.

Can i reprogram the board using a Jtag programmer?

Im stuck.

Omar F.

Omar,

You said before that you received the echo....that means you are communicating, as the echo is sent from the MSP430 based on the data that was sent to it.  In this case what happens is the UART receives the character, places it in a RX buffer (of one character size) and generates an interrupt.  The interrupt places the character in a RTOS buffer (queue).  If there is something in the queue, then the firmware pulls it out of the queue and retransmits it out the TX.  So, do you see an echo and does the echo also send a CRLF? If the RX buffer is overrun, then you will not get the CR that was sent, and the CRLF will never be echoed.  The end result is the command will never get executed.

As far as whether we have tried to communicate using another controller....no...there was no need to do that.  That is outside the scope of the reference design.  Again I remind you that you are using the board in a manner outside the scope of what it is intended to do.  It is a self contained weigh-scale reference design.

You certainly can do whatever you want with your board.  If you want to connect a JTAG you can do so if you solder a dual row connector to the side of the board.  You can then program the board via JTAG.  Do not expect to use an emulator unless you remove the RTOS code.....which means you would basically have to start over.

Best regards,

Bob B

Bob,

I got some good results I cut betwen Rx and TUSB the reason that a wasnt able to communicate,I think it was beacause of the isolator doesnt turn on. I put a battery with the Jtag switch and connect the usb to the computer and then I have communication with the board.

Thanks for your help im going to test this a while I see how it works.

Omar F.

Offtopic:

Why is this in the firmware ?, I know is an album of Severed Heads.

"Clifford darling, please don't live in the past"

Omar,

I'm glad you are finally making some progress.

As far as the quote....well often times programmers like to leave their mark in some way that uniquely identifies the code to themselves.  I didn't write the code, but I'm intimately familiar with it, and so I can fully appreciate why the originator left their mark...especially as this is the first RTOS project done.

Best regards,

Bob B

Bob,

Im sending 'sCR' command every 100ms to the board after a while like 1-2 hours later the MCU is in a off state. I dont know how often can i send the sCR command.

Omar F.

Omar,

You only need to send the 's' command once.  This is a STREAM command and it should just send the results until told to stop (which is any character sent.)  So what you are doing is sending a STREAM command, then every 100ms sending another STREAM command which halts the stream and then restarts it.  I'm not sure how the RTOS will handle this over time.

Another thing is the RTOS itself may be getting lost after a period of time and locks the processor.  This is an earlier version of freeRTOS, so I'm not sure if there are any specific bugs that would affect long term operation.

You could radically simplify the operation by writing your own code by just reading the data from the device and sending the data out the serial port.

Best regards,

Bob B

Bob,

And using "d" command, how often can i send this command?

Omar F.

Omar,

The 'd' command is really a debug command.  There is no real way to tell when (at what point in time) the data was valid.  This is strictly a RTOS response, so it depends on when the task is called in relation to the when the call was made.  The 's' is totally different as it sends the data out the serial port as soon as it is collected (interrupt driven).

The 'd' command was never intended to be used outside the debug role, so there is no information available as to how often this command can be sent, and if you get repeated data if you do operate the system in this manner.  I would assume that if you send the command every 100ms that from time to time you will get the same data more than once.

Best regards,

Bob B

Bob,

Im working in a project of a weigh scale using this board, im communicating with a device using UART but after a while im loosing communication with the board.

Im looking for a solution, im making a lot of test with different delays and commands. Any advice?

Omar F.

Omar,

Reread my posts...I think I've given you a lot of advice.  I believe you are trying to create a short cut by using this board.  Really what you need to do is design your own system for what you want it to do.  Create a block diagram of the system you would like to have and use the datasheet and reference design schematics to help you achieve your goal. 

My last post stated writing your own code using the existing hardware.  That is another option.

A third option would be to stream the data as it comes using the 's' command.  You don't need any delays, just process the data as it comes.

Best regards,

Bob B

Bob,

I have the same problems with a Vi that i make in the computer using the Usb, 4 hours later the ADS1232ref stop working. Im using sCrLF then another caracter to stop the streaming, Im just taking 1 sample at once because I cannot handle the streaming without overflow the buffer.

Omar F.