I have just bought the Olimex Rocket MSP430-BSL for programming through Python Tools (msp430.bsl5.uart) a CC430F5137. It doesn`t works because I realize that rocket firmware it's done for I2C BSL. I have downloaded the source code from -bsl and I've tried to change it for use with UART, but I don't have success. Also, I read all points of _(MSP430) to learn more about this hardware and its tools, using another tools like BSL_scripter, but I don't obtained any result.
I actually think that if you have the msp430-bsl code loaded in the olimex rocket board without any alteration, it supports both I2C and UART. It determines which interface to used based on if you change the baud rate on the USB side - for example, if I want to start the BSL in UART mode I go into my terminal program and set the baud rate to 9601 and this will cause the UART BSL interface to be used (you can find this in the IAR project if you look for 9601). The latest version of the BSL Scripter software from the download www.ti.com/lit/zip/slau319 sends this 9601 baud rate change for you, so it will get the rocket board to start the BSL using the UART interface automatically.
Rocket M5 Firmware 5.6 2 Download
DOWNLOAD 🔥 https://geags.com/2yGB9O 🔥
So I'd recommend going back and trying a fresh unaltered version of the msp430-bsl software (leave it with the predefined symbol for I2C_BASED), and try using it with the BSL Scripter software. Let us know if you keep having a problem, and we can look at your script and BSL connections to see what might be going on.
I've tried the BSL-Scripter with the default firmware of the MSP430-BSL Rocket and I don't have success. I run an example script only for view if the programm process starts on my CC430F5137, but nothing occurs. Only one fast reset at the beginning and then the CC430F5137 starts its normal program.
I did not have a CC430F5137 here so I used another device, but I was able to successfully use BSL_Scripter.exe with the BSL rocket board and the version of the rocket firmware that you mentioned from the wiki, version 2.1.
Additionally, one thing that I did not check on your connections is the Vcc connection. The Rocket board has two different Vcc connections - one for powering the target board from the Rocket, and one for the target board being externally powered. In my test I powered the board from the rocket, which means connecting the device Vcc to rocket pin 6. Is this the same pin that you used? Maybe you could provide BSL rocket pin numbers for your pin connections (rather than just saying BSL-TX, BSL-RX, etc)? Does your board consume a lot of current - in this case maybe you'd have to power it externally and make that connection instead.
We usually say you should have no more than 2.2nF capacitor on RST, so this would be ok. However, just in case your lines between the MSP and the rocket board are long (and so could have a lot of capacitance themselves) and for testing's sake, you may want to try removing this 1nF cap to see if it lets you into the part as it would be a fairly simple test to try.
Can you check the TEST+RESET lines with an oscilloscope? It also helps to load a simple LED toggle to the MCU (using JTAG) to check if the entry sequence is working or not. If the LED stops toggling, then the entry sequence is OK, and we would need to check the UART communication.
Now, I tried using the Rocket with a EM430F5137RF900 and I had some problems with the entry sequence, but I'm not sure if that's because I'm using an old pre-release silicon. In any case, the problem got fixed when I changed the following line in uart.c:
I have loaded your attached firmware, and now, at least the CC430F5137 chip puts in BSL mode (the main program stops running), although the communication still fails. I still have the same results for the MASS ERASE code as previous steps. The led 2 of the rocket board is set, and anything more occurs.
Based on what you tell me, the MSP430 is not executing the application anymore, so the BSL_RX line should be an input. A floating input if the device is in reset, or a UART input if the device is in BSL mode. In both cases, the MSP430 shouldn't be driving the line actively.
I can see that "Rocket RX" goes high and I assume that happens after the entry sequence when the MSP430 configures the pin as UART_TX. It's hard to tell for sure but that could be an indication that the MSP430 is really going to BSL.
Indeed, I am sharing the UART lines with a RS485 chip, but they don't have any pull resistor or capacitor in RX/TX tracks. I have removed it from the PCB, and the MASS ERASE script runs properly! Although, the script for transmit a new firmware doesn't do it, even the mass erase step fails.
But in others designs that I have (with MSP430F1611), I have the same situation, sharing the UART, and the UART BSL works properly, so I have searched others solutions instead removing RS485 chip, because it is not possible for our design:
I've tested removing the 100 Ohms resistors and bypassing them on the BSL lines of ROCKET and it works properly with the MASS ERASE script. But, as it happens above, the firmware programming doesn't work, even the mass erase step.
Until tomorrow I won't be able to do new tests, so what do you think about the failing of the programming script. Is it an electrical problem on lines? Or is it the script? Vcc and GND is ok, I have 3.3Vdc stable, and the length of the tracks are not long enough to have a large impedance that could produce electrical interferences.
1. After viewing the electrical problems in the UARTs lines, I have removed all the 100Ohm resistors from the Rocket. Cause I have shared the UART lines with a RS485 chip, this could be the source of the electricals problems. Removing the 100Ohm impedance in lines, I resolved it.
4. In my script, for downloading a firmware, I have had to put the Baudrate below or equal to 19200 in the first line after the MODE line. For larger baudrates, it doesn't work. For example, my script was:
Regarding your second question, I'm not really sure why the faster baudrate doesn't work, but do you happen to have any traces of the UART TX/RX? Is the MSP430 BSL acting incorrectly, the scripter, or the rocket?
I was able to replicate the problem and it seems to be caused by the Rocket board. When I was running tests, I saw that the MSP430 was returning the correct data via UART (by using a bus analyzer connected to BSL_TX and BSL_RX), but the scripter was getting incorrect data via USB (using VERBOSE).
Changing uart.py and bsl5.py, the msp430 python tools works now programming CC430 via Rocket msp430-bsl, but it has an odd performance. I mean that it works properly only when I execute the commands after a few moments behind resetting BSL rocket. If I connect the rocket BSL to my CC430f5137 circuit and pass more than a second, the python command doesn't runs: my circuit runs normally and never puts in BSL mode. I think that it could be any wait function or something like that. In addition, when I program the new firmware succesfully, my circuit never go out from BSL mode, even with parameter -r. This means that Rocket BSL maintain the reset line low.
This test has been done under Windows. Under linux, my python 2.7 don't recognize several lines of the files patched and makes impossible the running of msp430 python tools, so I haven't been able to program CC430f5137 under Linux. I think that the problem would be in the port selection, because it is different depending on OS. I have the problem that I don't know anything about the python coding.
With referent to second post, your firmware has enabled baudrates upper than 19200, although in BSL-SCRIPT I don't notice the new baudrates: it continues being slow. With python tool yes I notice it: is faster than bsl-scripter. Configuring baudrate at 57600 bps, with a 24KB firmware BSL-Script needs 26 seconds. On python tools, the programming takes below 10 seconds.
Because we wanted to design our own motherboards based on this CRB. I also contacted my account manager before, but did not find the finished product. So I couldn't buy a finished CRB or read the firmware from it. However, Intel engineers gave me a reference firmware, I am not sure whether this firmware can be directly written into this CRB to run?
And this CRB has an EC chip on it. Its model number is MEC1428. After my research, its program firmware is also in flash memory outside the chip. So, how do I know that the reference firmware also happens to have the EC chip firmware code?
I would like to let you know that we have a specific forum for this kind of issue and product, it is called the Intel Developer Zone. There you will receive the appropriate support on this and other concerns you may have related to this product.
First of all, thank you very much for your reply. I don't have a NUC host. Our company is designing a computer motherboard. At present is in the research and development of the design of the motherboard encountered a problem. Before we design, we need to evaluate some performance. The original plan was to purchase Intel CRB motherboards. The CRB meaning is Customer Reference Board. The existing technical documentation about it was obtained after I signed CNDA with Intel. But these documentation only have schematic diagrams and PCB layout, etc. There is no binary firmware file for this motherboard. Now we cannot purchase CRB finished products. We will make this PCB by ourselves. And now PCB empty board has been made, next we will carry out SMT process. Therefore, we need to confirm with Intel whether there is BIOS firmware that can run properly on this CRB motherboard. In this way , we can quickly determine that the motherboard we manufacture can work properly. The above is the background to the issue.
Answer: They are my account manager and my FAE. If you want to get more detailed contact information, you can provide you email address to me, I will email you. This is because a lot of details will involve the CNDA agreement between our company and Intel, so it is not convenient to disclose on the public platform. However, as you are an employee of Intel, it does not violate the CNDA agreement for me to provide it to you. 152ee80cbc
merry christmas and happy new year wishes video download
google podcast app download location