I am using a NUCLEO-G071RB. I implemented this modbus library: LINK. For testing I use ComTest Pro. Everything worked fine in the beginning. Then out of nowhere I started getting issues with 9600 baudrate. Some bytes get cut off and sometimes appear in the next response. This error only appears with 9600 baudrate. Baudrates 2400, 4800, 19200, 38400 and 57600 have worked correctly this far, but I also need to be able to use 9600.
I am new to STM32 and MCUs in general and the fact that errors only appear with 9600 BR is even more confusing to me. When I was using an STM32F446RE, the library worked fine and I didn't have any issues. Same issues appear when using an STM32F030R8.
Has anyone experienced same kind of issues?
EDIT: Out of nowhere it started working again, just like it stopped working. I even tried with project I didn't make any changes to and that works also, even with different RCC and clock configuration settings. Definitely interesting and I am more than sure it will stop working again at some point.
This is my RCC setup:
This is my USART setup:
This is my clock configuration:
I have tried different clock configurations and USART parameters, but haven't found any success so far. I read the reference manual, but didn't get any help from that either.
Related
I since a few months, I have been using a Hyperpixel 4.0 Touchscreen with my Raspberry 3B+ without any problems. Since a few weeks i use my touchscreen with the Raspberry Pi 4 Compute module and mounted both on my own designed PCB. Unfortunately, I’m facing some difficulties with the Touch function of my Hyperpixel 4.0. I have no clue how to solve these problems because the circumstances, which cause the fault don’t make sense to me.
Which System do I use?
Hyperpixel 4.0 in combination with Raspberry ComputeModule 4 with 2GB RAM and 8GB onBoard eMMC. Both is mounted on my custom PCB, which is supplied with 24V, stepped down by an «APP63300WU-7» Step down converter, which provides 3A # 5.1V continuous output. The measured Voltage over 2 Days of measurement is a maximum of 5.2V and a minimum of 5.05V. The software ist the latest Raspbian.
What error is caused?
I have been running a GUI on my Raspberry Pi. I have one Page on which i have three sliders for changing brightness of my room light, colortemperature and one slide is to regulate the speed of some fans. Everything works fine in darkmode, but if I change to lightmode and touch the screen for about 1.5 seconds, the touch- function hangs up. My GUI doesn’t move anymore and I have a still image. I know that it’s only the touch function beacause if I plug in a keyboard and mouse, I can open for example chromium or other stuff without problems. With «i2cdetect »-command I can detect the Goodix GT911 driver on Address 0x14. Even if the touch has hung up, i can detect the Goodix GT911. I know that the address should probably be 0x5D but I thought it isn’t necessary to care about this problem as long as it works. After a reboot, the touchscreen works fine again until i use the lightmode of my GUI. Interesting to mention is, that i can click a thousand times for around 0,25seconds and no problems occur. But if I touch the screen permanently for around 1,5seconds, I instantly get my above described problems. Generally considered, this problems seems very strange to me and it doesn’t behave like any physical law i know…
On the first view, the error seems like a software issue ? Hear this!
If i use the official «Compute Module 4 IO-Board » to mount my Compute Module and Touchscreen, I don’t get the issue at all… My actual designed PCB ist the 2nd version. On the 1st version It also worked fine without any problems. The only differnce between version 1 and 2 is the wiring, which I tried to improve on the 2nd version and viewer parts which I only put on my 1st version to evaluate some functionalities like ethernet or 2nd I2C-Bus, which I’m not using on my 2nd version. The wiring did not change between these two versions, i only tried to increase the distance between the GPIO-traces to improve signal integrity.
So it seems like a hardware problem? But why does the GUI work fine in darkmode? I don’t have any explanation to that.
What did I do to narrow down the error?
I flashed a new image on my Compute Module and also used another Compute Module, Custom PCB and touchscreen as well, but without any success. As far as I experienced, the issue is only caused on my GUI and not on any other websites or images, etc. An interesting thing was the interrupt line, which is typically only drawn to 0Volts if the touchscreen gets touched. After the touchscreen hung up, I measured 0,084V on that line and as long as I touched the screen, this voltage rised to about 0,2V, which for me seems also like a strange behaviour. I also checked the «dmseg» file and got some entries for failed i2c tests of the GoodixGT911. I also tried the github fix for the swapped i2c address, but without success. I used the command «git clone GitHub - pimoroni/hyperpixel4: Driver for the Pimoroni HyperPixel 4.0" Touchscreen Display -b pi4-i2c-fix » for that.
What do I try next?
I dont have any clue what to do next. My only solution in mind, is to undo the «improved» wiring of my 2nd PCB to get as close as possible my first PCB version.
Conclusion :
I really need help and hope, someone can do me this favour. I’ve never found my described error behaviour in any forum. Are there any other usable forums for problems with the Hyperpixel 4.0? Let me please know.
Update:
I tried to reproduce the errors and specify the error source. As above mentioned, the touchdriver hangs up on lightmode (nearly every pixel on rgb(255,255,255)). If i change the color in lightmode to around rgb(245,245,245) the error does not occur. I also noticed that there are two flatband cables on the Hyperpixel 4.0: One for displaying the image and another for the whole I2C-Communication to the touch driver. I plugged out the one for displaying the image and got no problems at all. Even if was theoretically in lightmode(if display would have been on). The touchscreen worked fine and transmitted everyting flawless:
Conclusion on my Update: It seems as the rgb(666) datalines for displaying the image on the screen cause some problems on the I2C bus. I also checked the bus and the power supply with an oscilloscope but I haven't seen any unusual behaviour in any case. Voltage ripple was around 200mV Peak to Peak and the I2C-Datalines rised and fell really sharp
I still need help from you!
Thanks, Manuel
I recently had a frustrating problem:
Modbus-connection throws in bError 4 as soon as bExecute is turned on. No variables could be read, and error persisted until reboot.
Previously working project stopped working over the weekend.
I might have fiddled around inside PLC, uninstalling couple libraries mainly, but logically thinking nothing should be wrong and I didnt do much at all. Its still possible I done goofed on friday, and didnt notice until after weekend.
On to the troubleshooting:
Reboot both machines
State machine is fine. Even made stripped-down project with one input and output and previously working minimalist state machine.
Reinstalled Modbus library in PC and PLC
Git revert the code couple weeks to a time when I 100% knew it worked.
PLC can ping PC in 1ms
Had an old project zipped in store, including "original" libraries
Reboot again
I still could wipe out PLC OS and start anew, but lets save that off for now.
"Thats all a mere mortal can do." I thought, and shot off a mail to Beckhoff.
Lets shoot off a mail to Beckhoff support.
Troubleshooting ensues:
Strip down the program even further, so only FB_MBReadInputs stays and bExecute can be flipped on or off manually.
Running only MBReadInputs, only MBWriteCoils, both at the same time
bError 4 problem persists no matter how much is stripped or ran.
Running the same project Locally on PC works just fine. Inputs can be read and output bits can be written.
In the end, flashing new image ended up being the solution.
Still in process of fiddling that out, so the actual problem isnt yet solved.
Update: Stuff works as it should. Some cosmic ray must have hit SD-card just right so during the weekend things got awry and problems surfaced.
Beckhoff image repo in my case: https://download.beckhoff.com/download/software/embPC-Control/CX90xx/CX9020/CE/TC3
Thats it, in the end wiping out SD-card is pretty basic thing to do when facing larger problems, but I just wanted to go through all the troubleshooting steps and end results for anyone struggling with Modbus and Twincat as much as I have.
I just reached out the same problem on CX8180. In my case there was some program uploaded before mine. I've activate my configuration and run PLC - get bError 4. TwinCAT errors code list says that is something with ADS mailbox and too much ADS calls. My program works fine on the same hardware elsewhere. Restart origin and activate configuration doesn't work.
I need to login with CeRHost and make a reboot of PLC. After that move communication works like a charm. The problem was the previous modbus communication.
I just got a STM32H747I-DISCO board. When I try to debug it and load the code to it by using its internal ST-Link and STM32Cube IDE. It says :
Break at address "0xa05f0000" with no debug information available, or outside of program code.
And when there comes a little option( View Disassembly) that leads me to some assembly code. How can I fix it? I am just trying to make simple led blinking. To be honest I have no idea how to use this board. This is my first time with it, maybe I am trying to write codes to the wrong core? Or maybe the problem is in the debug properties. I am stuck with it. How can I fix it?
Edit: Okay so I have figured out that it also gives "Program received signal SIGTRAP, Trace/breakpoint trap." error. I believe that is related to GBD but ı don't know how to work with GBD in STM32.
You seem to be making some very trivial error in your code. Since this is led blinking, I am assuming you must have either missed out on some library import or forgot to have provided clock to the I/O ports.
Also, do set up the mode to PULLUP if you are just doing LED blinking.
The above is pure speculation since I haven't seen your code yet.
Setup: Matlab Student 2014, Psychtoolbox 3.0.12, GStreamer 1.4.3, ATI Radeon 69xx, all on Windows 7, all 64bit.
Screen works with different arguments, only at Screen('OpenMovie' the whole Program (Matlab) crashes - sometimes with Error (unable to synchronize framerate), sometimes no error at all.
I know it is quite specific and I think it is somehow in my configuration (the code will work on a different system (lab)).
What I've tried so far:
Psychtoolbox 3.0.11, GStreamer SDK, GStreamer 1.4.1
renewed ATI drivers (complete catalyst control center,..)
removed multi-monitor setting (makes it harder to debug then..)
Matlab itself works, GStreamer too (tried playing movie with playbin)
anything SyncTrouble states: wait for vertical synch, triple buffering off
overriding sync-tests or skipping at all (also crash)
looking for missing dlls (for Screen.mexw64)
VBLSyncTest and PerceptualVBLSyncTest look fine and have results (for me)
It has to be either something very simple, or very specific - I'm somehow out of ideas. My guess would be that the Radeon vertical sync on setting does not work - for what reason ever.
ANY guesses, tips are apreciated. (even other ways to test Screen or vertical sync in Matlab/Psychtoolbox)
after hours of search, I think I've found a solution - oh Windows! (and oh, one simple line of code)
Screen('Preference', 'ConserveVRAM', 4096);
4096 == kPsychUseBeampositionQueryWorkaround
Tell PTB to always use the workaround for broken beamposition queries in
VBL on MS-Windows, even if the automatic startup test does not detect any
problems. This for rare cases where the test fails to detect broken
setups. [Psychtoolbox Docs]
I will do a recheck after some Videocache action and restarts.
edit:
well, that did only work once, and randomly a second time - it seems like the ATI Radeon driver behave not quite deterministically - I also checked on a Linux (Ubuntu 14.04.1). Specifically, the VSync rate seems to behave somehow strangely.
It generally works on that specified Linux with the open source radeon drivers (instead of the fglrx ones) though. -> The Problem on that Linux system: it can only be configured as one Screen (two monitor setup would be nice for debug on one Screen). (Yes, I've tried: Unity, Gnome, Xmonad, Gnome+Xmonad - but I guess that is another story)
Alright, I've written enough, my solution: use a Linux distro (quite unsatisfying though, as I could not accomplish for everything to work).
I am having some trouble uploading code to my Seeeduino ADK (essentially a Arduino Mega 2560) using Eclipse. Basically, this thread explains my problem. Sometimes I get a series of timeouts using the Arduino IDE upload, which is usually fixed by removing and re-inserting the USB. Unfortunately enough, this does not help fix the problem in Eclipse.
I have been trying to do the upload using AVRdude via the command line (I even tried the "hacky" solution in the last comment of the above thread), but to no avail. This is the line I am using for this:
"%AVR_DUDE%" -pm2560 -cstk500v2 -P\\.\%COMM_PORT% -b115200 -F -V -D - Uflash:w:"%HEX_FILE%":a -C"%AVR_DUDE_CONF%"
Which gives me:
avrdude.exe: stk500v2_ReceiveMessage(): timeout
I know the above batch variables are OK, because AVRdude runs correctly (but then it times out). If anyone has any ideas or tips that could help me with my uploading I would greatly appreciate it. Thanks beforehand.
EDIT: As it turns out, the reason for this may be that the Arduino IDE sends a reset to the board before uploading, something which the Eclipse AVR plugin does not do. I will test this and write a uploading perl script, but I am fairly certain this is the problem.
Your suspicion is correct. The Arduino IDE uses a patched version of AVRDude to pulse the DTR line and reset the board before each upload. For some reason, some people have had difficulty getting the right command line parameters to replicate this on the Mega2560. I've had the same problem myself - ATMega328's work with no problem, but the 2560 needs to be reset manually.
There's some further explanation and tips for possibly getting it working here (check the comments too): http://false.ekta.is/2011/05/avrdude-5-10-arduino-mega-2560-command-line-uploading/
Check out the detail here... http://false.ekta.is/2011/05/avrdude-5-10-arduino-mega-2560-command-line-uploading/
If using avrdude > version 5.1 change the programmer to -cwiring
This will reset the chip first