Hi all,
I am designing a custom PCB employing a MSP430FR5969, being programmed using CP2102 in a similar fashion after referring to this blog;
and
and
after going through above links I have developed the following schematic ;
Q1. Is the schematic correct?
Q2. Is connection of DTR (of CP2102) needs to inverted and then connected to RESET of MSP430FR5969?
Q3. Do I need to take care of any other precaution?
Thanks and regards
George Hug said:The second reference in your post concerns using a CP2102 to program a G2553 device. The G2553 is an older device which is programmed with TI's software BSLDEMO.exe. That program directly outputs the required pulses on DTR and RTS to initiate BSL, although the polarity of DTR is wrong when using the CP2102.
However, the FR5969 is a newer part with completely different BSL protocols than the G2553. It is programmed with TI's BSL Scripter software. Unfortunately, Scripter does not generate the DTR and RTS pulses at all. It depends on a "Rocket" or MSPFET programming device to do that.
So I do not believe your idea will work unless (1) you write your own software to program the FR5969, (2) you re-write BSL Scripter to give it the option of issuing the DTR and RTS pulses directly, or (3) TI does that re-write for you (and for all of us).
In the past I tried to understand what is addressed in your first reference, but was unable to make sense of it. All of the internal links are broken, and I just couldn't understand what he was doing.
So far as I know, no one has been successful at using a simple CP2102 adapter, or one like it, without a Rocket, MSPFET or equivalent third-party device, with BSL Scripter. This is unfortunate because if a product requiring BSL Scripter is sent out to customers, there is no practical way to do firmware updates except to include a programming device that may cost more than the product itself. This is not the case with the older parts using BSLDEMO since the CP2102 modules are very inexpensive, and a CP2102 can even be embedded in the project circuit for a couple dollars.
I was able to generate the BSL invoke sequence mentioned in SLAU550(Figure 2, Page No.- 7) with the following code:
Link
But when I tried to run the BSL_scripter after running this, I got the following output:
I'm using cp2102 with MSP430FR5969 and compiled the BSL_invoke.c with GCC 8.2.1 20180831 under Manjaro Linux.
#include <stdio.h>
#include <fcntl.h> /* File Control Definitions */
#include <termios.h> /* POSIX Terminal Control Definitions */
#include <unistd.h> /* UNIX Standard Definitions */
#include <errno.h> /* ERROR Number Definitions */
#include <sys/ioctl.h> /* ioctl() */
#include <stdlib.h>
#include <time.h>
#include <unistd.h>
struct timespec ts;
void sleep_ms(int milliseconds)
{
ts.tv_sec = milliseconds / 1000;
ts.tv_nsec = (milliseconds % 1000) * 1000000;
nanosleep(&ts, NULL);
}
void main(void)
{
int fd; /*File Descriptor*/
/*------------------ Opening the Serial port ------------------*/
/* Change /dev/ttyUSB0 to the one corresponding to your system */
/* O_RDWR Read/Write access to serial port */
/* O_NOCTTY - No terminal will control the process */
/* Blocking Mode */
fd = open("/dev/ttyUSB0",O_RDWR | O_NOCTTY );
/* Error Checking */
if(fd == -1) {
printf("\n Error! in Opening ttyUSB0 ");
}
else {
//printf("\n ttyUSB0 Opened Successfully \n");
}
/*--------- Controlling the RTS and DTR pins of CP2102 to generate BSL invoke sequence --------*/
int RTS_flag, DTR_flag;
RTS_flag = TIOCM_RTS; /* Modem Constant for RTS pin */
DTR_flag = TIOCM_DTR; /* Modem Constant for DTR pin */
/* Initially making RTS and DTR line HIGH as whenever the /dev/ttyUSB0 port is
opened, DTR and RTS becomes LOW by default */
ioctl(fd, TIOCMBIC, &RTS_flag); /* TIOCMBIC - Clear the bit corrosponding to RTS_flag */
ioctl(fd, TIOCMBIC, &DTR_flag); /* TIOCMBIS - Set the bit corrosponding to DTR_flag */
sleep_ms(3000);
/* Genrating the BSL invoke sequence as mentioned in SLAU550(Figure 2, Page No.- 7) */
ioctl(fd,TIOCMBIS,&RTS_flag);
sleep_ms(10);
ioctl(fd,TIOCMBIC,&RTS_flag);
sleep_ms(100);
ioctl(fd,TIOCMBIS,&RTS_flag);
sleep_ms(10);
ioctl(fd,TIOCMBIS,&DTR_flag);
sleep_ms(10);
ioctl(fd,TIOCMBIC,&RTS_flag);
sleep_ms(2000);
/* Close the Opened Serial Port */
close(fd);
}
Also attached the example script that I used with BSL_scripter
MODE FRxx UART 9600 /dev/ttyUSB0 RX_PASSWORD /opt/ti/ScriptExampleLinux/FR5969_blink_led/pass32_wrong.txt DELAY 2000 RX_PASSWORD /opt/ti/ScriptExampleLinux/FR5969_blink_led/pass32_default.txt RX_DATA_BLOCK /opt/ti/ScriptExampleLinux/FR5969_blink_led/Blink_led.txt SET_PC 0x4400
@4400 81 00 00 24 B1 13 00 00 B1 13 5A 00 0C 43 B1 13 2C 00 1C 43 B1 13 54 00 32 D0 10 00 FD 3F 03 43 @ff80 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF @ffcc 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 18 44 00 44 B2 40 00 A5 A0 05 3F 40 40 04 82 4F A6 05 3F 40 40 04 82 4F A4 05 3F 40 13 15 82 4F A8 05 3F 40 01 A5 82 4F A0 05 C2 43 A1 05 10 01 F1 03 B2 40 80 5A 5C 01 92 C3 30 01 D2 D3 04 02 D2 E3 02 02 B1 40 10 27 00 00 91 83 00 00 81 93 00 00 F6 27 FA 3F 03 43 03 43 FF 3F 03 43 1C 43 10 01 q
@FFE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF q
@FFE0 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 q
Hi George,
George Hug said:First, I should say that I know nothing about Linux. So I have to leave it to you to make sure that the designation of the COM port in the MODE line is correct. In Windows it would be the name of the virtual COM port created by the Silabs driver, and there would be no mention of "USB". But I don't know how that works in Linux.
I checked for the port name, it is correct and its opening the port successfully.
George Hug said:Otherwise, I'd suggest you try adding PARITY at the end of the MODE line. SLAU655F says Scripter defaults to no parity, but almost all BSLs require even parity. Normally the Rocket or MSP-FET generates the parity bit, but since you are using the CP2102, I think you need to turn on even parity in Scripter, which is done by adding PARITY to the MODE line.
For testing, after sending the wrong password leading to mass erase, followed by the default password, I suggest you just do a TX_BSL_VERSION just to see if everything is working in both directions.
Ok, will try this.
George Hug said:Thanks very much for the DTR/RTS code. If you have a link to a Windows version, that would be helpful. Otherwise I may try to write one. I think having a separate executable generate the BSL entry pattern in advance of running Scripter will be very useful, and will permit using standard USB-to-UART adapters like the CP2102 with Scripter.
Seems like you already figured out but anyway, this link migh be helpful.
George Hug said:Edit: I thought of another possible problem. If Scripter intializes DTR and RTS when it opens the COM port, then this method may not work. If Scripter takes DTR low at the beginning, then the FR5969 will reset, and the BSL session will be cancelled. Taking RTS to the wrong state may not be a big problem if it is only temporary. Your code must leave these lines at the correct state after initiating the BSL session (DTR high, RTS low), and Scripter must not change them when it runs.
I checked the signals through logic analyzer. when BSL scripter starts, it pulls down the DTR and RTS lines of CP2102. I have gone through its code, I think it is using libusb for controlling the RTS and DTR lines. We may have to recompile the BSL scripter code to remove that DTR/RTS part.
When BSL-scripter is transmitting then MSP430FR5969 is giving some reply as shown in the below image(look for TXD and RXD line):
George Hug said:I wrote a Windows version of your program, and when it exits it leaves the two lines in the correct state - /Reset is high and TEST is low. But when BSL-Scripter runs, it resets the DTR line, and with /Reset low the processor cannot function. I got the same error you did, but with no device attached, so I think it's likely that your FR5969 is in reset when Scripter is running, and is doing nothing.
I have changed the invoke sequence part in the code as the previous one was generating incorrect sequence(Updated the repository). I also found out that tSBW,EN must be between 250ns(slau550p, Page 7, Figure 2) and 110us(MSP430FR5969 datasheet, Page 52, Table 5-35)(Added sleep_us function in the repository to deal with this). But with my code, I wasn’t able to generate tSBW,EN less than 386us(As our systems are multi-threaded so maybe the OS is handling some other process instead of the sleep_us function). Would look for some way to generate accurate timestamps. I haven’t gone through the BSLdemo code, but as you are quite familiar with it and you also mentioned before that it does generate those DTR/RTS sequence, so which system library do they use for that?
Following is the generated invoke sequence:
Looks right to me(According to slau550p, Page 7, Figure 2). I also made the TEST line LOW well before starting the invoke sequence(mentioned in slau550p)(This wasn’t there in the previous version of my code). Let me know if there is something wrong with it.
George Hug said:I don't know what the solution to this is except to recompile Scripter so that it leaves DTR and RTS as it finds them. But that may mess things up for using the Rocket or MSP-FET.
Yes, most probably we have to recompile it. We can add an option to choose between Rocket, MSP-FET or CP2102(can be given in the argument)
**Attention** This is a public forum