I am interfacing LCD module in 8bit mode to STM32F446RE Nucleo board the connections are as below:
connections
wiring (if pic is not clear)
PB0-->RS PB1-->RW PB3-->E
D0-D7-->PC0-PC7
code
Dear members,
I have pasted all my codes.. in the link above The GPIO.h,.c files are 100percent working fine I have checked with other peripheral projects. The delay function also works correctly tested for led blink..
Now I am stuck in LCD program only..
My main aim is to just display 1 character I have gone through datasheet and forums and have taken everyones's suggestion accurately I still can't figure out what's wrong with my program..
I have tried this LCD board for arduino program it works there.
Also I have checked voltage specifications and all pin's connected are 5v Tolerant as per stm32 datasheet.
Please can someone figure out whta I may be doing wrong..
Your suggestions may help me..
I would be greateful..
I have two nucleo boards (F4339ZI and F303K8) and neither of them show up as USB devices when I plug them into a computer via the USB port (CN1 - the USB micro port on the ST-Link, not the USB port for the board itself).
I have tried multiple host USB ports, with and without a USB hub, across two different computers, one running OS X and one running Linux. I have tried at least 6 different cables. The OSX machine is using a USB-C to USB-A converter (if that's the correct terminology). The Linux machine has USB-A ports.
In no case does the device show up using lsusb under Linux or system_profiler SPUSBDataType under OSX. Needless to say STM32CubeIDE and st-info can't see the boards. Other USB devices are functional.
The COM LED is slow blinking red which the manual (https://www.st.com/resource/en/user_manual/dm00244518-stm32-nucleo144-boards-stmicroelectronics.pdf) says means USB enumeration hasn't completed (matching what is seen from the OS level).
The boards successfully run their factory supplied blink programs when powered on.
I have tried (with the F4395I) moving JP3 to VIN so the board doesn't power up which should just leave the ST-Link running - still no enumeration though.
I tried connecting to a USB charger with JP1 off (and JP3 on U5V) and the board powers up and blinky runs. The manual referenced above says:
In case the board is powered by a USB charger, there is no USB enumeration, so the green LED LD6 stays in OFF state permanently and the target STM32 is not powered.
But everything works for me - LD6 goes a steady green as it does when connected to a computer.
Given it happens with multiple computers, OSs, cables and Nucleo boards I assume the error lies with me, the common factor in all the tests. This is my first use of Nucleo boards so I may well have a mis-assumption.
Out of frustration and lacking anything else to try I dug up every micro USB cable I could find. One had chokes on each end and magically, using that cable, everything just works as expected.
Can it be that I have at least 10 broken USB cables? I don't have an easy way to test them but I guess they might not have the data lines wired to save cost if manufacturers assumed people would only charge phones with them. I don't recall where they all came from...they have just accumulated in a box of USB cables.
Perhaps the Nucleo board sensitive to some horrible interference floating around my room?
Sorry for the noise! Broken cable was genuinely one of the things I suspected - but not 6 of them...
I am building a system which uses a remote attached to the RPi with a ribbon cable from about 3ft away.
The remote has buttons on it which connect the Raspberry Pi's
GPIOs to GND.The system works beautifully when I use a breakout board, plugging the ribbon cable into that.
However, when I tried to connect the ribbon straight to the RPi,
pressing 1 button often triggers 2 others.
Why would this happen only at the RPi, but never at the breakout board? Any help would be much appreciated.
Before I could preview the schemtaic circuit of the breakout board. I doubt it is caused by the drive capability of the pi board,you can mesure and compare the voltage on the button end between using breakout board and without it, it's really a hardware issue and only way to solve is to check the schematic circuit and measure. by the way, the question you asked is off-topic here.
My question is, if I manage to develop some kind of bootloader and flash it (is it called that when you put a bootloader on an MCU?), and it works horribly, can it brick the MCU entirely, making it completely unusable, permanently?
The reason I'm asking is that I've been tasked to develop a bootloader for the STM32F407. Problem is, I don't know anything about bootloaders or anything of the sort, which means that I have a lot to learn.
I appreciate any answers, thank you!
In short no you cannot brick a microcontroller with a bootloader.
In the end bootloader is just a firmware and can be erased away using the programmer via SWD
Erase the flash and your controller is as good as new
In general, absolutely, I have a collection of bricked microcontrollers, every so often I get lazy and there goes another.
It is very specific to your microcontroller and family. For example, pin count is very important, as much bang for your buck as you can get, if your microcontroller relies on certain pins for in circuit (or even in a programming fixture) and those pins can be repurposed by software. For example jtag pins that can also be gpio pins. And your code for some reason uses them as gpio pins, AND the design of the chip is such that they cannot use the jtag interface when the chip is in reset, then you can get bricked.
Another very easy one is the pll or clocks in general. If/as you develop code to initialize the clock system (assuming you choose to do that, even if you use chip vendor supplied code) and you have a bug that switches the chip over to a clock that you have not properly initialized or isnt there, it might brick.
Now some chip designs, many, help you out in various ways. The AVR family in general there is a programming mode that happens while the chip is in reset or is related to reset such that whatever code is in flash cannot affect its functionality, you can have a bad board design, sure, but your code cannot prevent it from working. Another method is a "strap" a pin (or pins) that is dedicated to a boot function, set one way normal boot, tie it the other and it goes into an alternate bootloader. This is what you have on the stm32 boot0 and sometimes boot1 depending. that is your get out of jail free card for that chip family, if you brick your chip (pll/clock or mess up the SWD pins by using them as gpio), you "simply" change boot0 and it boots into an internal bootloader (which AFAIK you cant mess up) which is known to work. From that bootloader you can use SWD (chips not bricked now) or the bootloader itself (always serial, sometimes usb or other is supported). NXP similar deal. Atmel ARMs used to have (do have) SAM-BA now they really only support SWD, you can get some samba code and try to lock it into the flash, but way too easy to unlock and or trash that flash, so that is a fail on their part.
As part of your system design if you dont have one of these built into save you from bricking features (like boot0 on an STM32), then I recommend you add one. Very early code initializes a dedicated gpio pin as a strap into your software, if that gpio pin is pulled one way do a normal boot, if pulled the other then spin in an infinite loop or jump to some other guaranteed to not be buggy code. Not a complete guarantee that you wont build the project wrong and trash this code, but it at least allows you to develop your bootloader/project and not brick a tray full of parts/boards as you work through the peripherals that can brick it.
Note letting smoke out of the part is another way to brick it as well, and that can/does happen from time to time as well.
Lots of examples on how to boot an STM32, plus various code from ST that you can use as a starting point as well. (all of which is of various quality, you get what you pay for). Their docs are good, better than some of the competition, not difficult at all to boot and configure their peripherals, sometimes easier than trying to use a canned library. YMMV, you should try various solutions. But if you are new to this, bricking is highly likely, fortunately you have a chip that you cant brick so long as your board design breaks out the boot0 pin. For a prototype board for an STM32 I prefer to have a boot0 button and a reset button, just reset resets the chip and runs, hold boot0 and press reset and it goes into the bootloader. both have to be wired in properly with the right pull up or down as needed for this task. or a jumper works tie boot0 directly high or low then pop reset, costs you more time, but works.
Yes You can brick the Micro controller to never recovered state. I did this and i did it in STM32F427.
Bootloader is all about carefully selecting Clocks, Peripharals and Interrupts priority. if you do this, there are less chances to brick the controller. Also test everything before release your code as some companies wants to save proprietary information to be saved so they blow up the JTAG lines, the only way to program is via Bootloader and if it is not perfect, voila, you just bricked the controller.
I hope you can help me. I am trying to build a robot but I am kind of stuck. The Arduino Mega is controlling the stepper motors drivers of the robot. The odroid-x is a single board computer that has installed linaro ubuntu and eclipse c++. All the programming is done in C++ and OpenCV is an image processing library.
The odroid-x has only as input a color camera. Therefore, the information from the camera is received and is processed in eclipse. Then, according to the information that is received, the odroid-x should send different integers to the arduino. The arduino should have a program already uploaded in itself, so it will be waiting for an integer and that integer is going to determine what the arduino is going to send to the drivers.
My questions are the following:
How can I do a serial communication between the arduino and the odroid-x?
How can I send information from eclipse to the arduino with a serial connection?
Thanks so much for any guide you can give me
First, be very, very, very careful. The ODROID boards use 1.8V signalling, so hooking up your 3.3V or 5V Arduino to the pins that expect no more than 1.8V will give you a burnt ODROID-X. It is possible to hook these two boards together if you put a level converter between them, and Sparkfun and Adafruit have some of those converters available. There is even a 1.8V reference voltage pin available... one of the pins that go to the LCD panel RGB-to-LVDS converter board puts out a constant 1.8V.
You could use either the four pins of the little white connector, or UART1, as a serial port, or you can use some of the pins in the 50-pin GPIO block as UART4. There are board schematics available on Hardkernel's website. These two UARTs show up as /dev/ttySAC0 (UART1) and /dev/ttySAC3 (UART4).
I don't know how to talk to those UARTs from a program, personally, but I know there are serial communications libraries available for python from watching threads pop up on the ODROID forums.