I am working on a university project in which i need to interface pic18f4550 with i2c EEPROM.
I implemented the following circuit using proteus simulator. The following in my connections
when I implemented the interfacing on real, I faced a problem when the PIC reads from the eeprom. it is suspended and so I was not able to see if the reading operation was performed correctly.
What could be the problem?
You do need to make sure you are following the I2C protocol for reading an EEPROM, and that is best served with a state machine on a PIC.
Try sequencing through the following actions, making sure your flags are set correctly:
Start condition
Write to the EEPROM with the address to which you want to read.
Repeated Start condition.
Read from the EEPROM as many bytes as required (keep in mind that the EEPROM is paged, and you will roll over if you go past a page boundary.)
Stop condition
Related
I am trying to make some custom firmware for a MIDI controller (AKAI LPD8).
There is an STM32F102R8T6 chip in the unit.
I am trying to reach it with a programmer to wipe it, but it seems to not be responsive.
Some information and thing I have tried:
The firmware that came with the unit works, so the chip is not broken
Removed the components connected to the programming pins (PA9-PA10 and PA13-PA14)
I am able to pull BOOT0 high and have it not run the main program, but I am however not able to get a life sign using either an ST-Link2(clone) connected to PA13/14, nor a USB to serial adapter connected to PA9/PA10, so I am not sure what mode it is in
The connection has been checked, and RX-TX etc is the correct way around (but also for the sake of trying it all, I reversed the connections as well...).
Tried both the STM32CubeProgrammer and stm32flash, but none connects.
I am actually not sure if AKAI have locked the chip in such a way that you cannot even do a full chip erase and use the chip for something new? The NRST pin is strangely not doing anything to the running of the firmware either when I try to pull it low.
Is there a way to reprogram these chips when they come off of a commercial product, or are they permanently locked?
Any solution/tips?
Many of the STM32 parts have "proprietary code read-out protection" (google PCROP) which but you might be lucky and they haven't enabled it in the option bytes. Read the documentation for that and the bootloader documentation and get a good idea of what you expect it to do if it is enabled and if it isn't.
If you have a scope, try watching the SWD/JTAG pins to see if there is any response from the device. (If you aren't even sure if it is in reset then scope the crystal if there is one).
If you haven't got a scope, you might be able to to verify what it is doing by seeing if it sets the pins and pull-resistors to how they would be expected to be in the bootloader mode, eg: UART TX should be high if it is enabled, even it it isn't transmitting anything. Put a strong pull-down (~1k) on there and see if it still reads high.
After hours of trying different ways of making it work (also tried the alternate mapping of the UART port), and probed the TX pin as suggested by Tom V to no avail, I have given up working on that specific chip and ordered an upgrade from the STM32F4 family instead to replace it with. A lot more power and useful peripherals.
A bit of a non-answer to the specific question. Frustrating to not have found out what was wrong (chip or approach) but being mindful of the sunk cost fallacy, I think it was best to just replace the chip with a fresh one and start development from there.
I'm using STM32f103 and in my program, I need to save some bytes in the internal flash memory. But as far as I know, I have to erase a whole page to write in it, which will take time.
This delay causes my display to blink.
Can anybody help me to save my data without consuming so much time?
Here is a list that may help:
1- MCU: STM32f103
2- IDE: Keil vision
3- using HAL driver provided by STM32CubeMx
4- sample data for saving in Flash: {0x53, 0xa0, 0x01, 0x54}
In the link below, you can find the code that I'm using.
FLASH_PAGE for Keil
The code you provide doesn't seem to be implemented well. It basically does 2 things each time you initiate a write operation:
Erase the page (this is the part that takes time)
Start form the given pointer, write until it hits a zero.
This is a very ineffective way of using the flash.
Probably the simplest and the most well-known way is to use the method described in ST's AN2594, although it has some limitations.
Still, at some point a page erase will be necessary regardless the method you use and there is no way to avoid some delay, unless your uC supports dual flash banks (STM32F103 don't have this feature). You need to plan the timing of flash writes and display refresh accordingly. If you need periodic writes to the flash, there is probably some high level error in your design.
To solve this problem, I used another library that STM itself presented. I had to include "eeprom.h" into your project and then add "eeprom.c" to it. You can easily find these files on the Internet.
I'm facing an unexpected problem with stm32f103c8. I'm programming the chip and after reset, it starts to run the program, but after a few seconds the microcontroller getting mixed up and stops running the program. After that when I try to reprogram the microcontroller, IDE(IAR EWARM) tells "target held in reset state".
It's very unusual issue because sometimes when I connect nRST pin directly to the VCC(3.3V), microcontroller runs program but unfortunately the current goes over 120mA and chip breaks down finally.
I'm using STM32CubeMX to generate the codes and my programmer is STLINK V2(clone), also tried Jlink V8.0(clone) but didn't change the result.
Could it be because of the clone programmers?
Can anyone help me solve this problem?
Thanks
Never connect nRST directly to VDD/VCC. This is a bi-directional input-output which must only ever be connected to an open-drain/open-collector signal. It can be pulled low externally or from within, it must never ever be pulled or driven high other than by the internal pull-up resistor.
When your debugger or programmer has finished programming the flash and wants to start running the new program then it requires to be able to pull this line low, which it might do externally if you connect this line to it in hardware, or else it has to be able to pull it low by software using the internal reset pulse-generator. If it does this and you have tied the line high externally then you are effectively shorting out your power supply, which is the cause of the over-current condition that you have observed.
Maybe the original problem is that your counterfeit ST-Link has its reset output configured as push-pull when it should be open-drain.
I would suggest that the easiest way to proceed is to leave the nRST line unconnected and configure your programming tool to use a software reset only.
I'm having trouble with i2c communication. In my i2c bus, i have 4 boards (STM32L4 Sensortiles) and sometimes one of them blocks the bus and the others stop communicating consequently. When I reset that one that blocks the bus, all boards starting working again.
In my debugs, this bug happened when HAL_I2C_GetState(&hi2c3) returns HAL_I2C_STATE_BUSY_RX, even my others i2c functions HAL_I2C_Slave_Receive_IT and HAL_I2C_Slave_Transmit_IT returns HAL_OK:
Any ideas what Im doing wrong? Thanks.
Using libraries like HAL leads to problems like this one. Why?
HAL users feel free from knowing your hardware as magic library will do everything for you.
HAL users usually do not know how the peripheral works and how to debug it.
HAL users do not bother to go through the magic HAL function to see what the problem is.
Posting some images form debugger will not help.
What you need to do:
Get even the cheapest logic analyzer (there are $10 on ebay) and record the communication. See if the slave keeps the clock or data line low. If yes toggle the clock pin 9 times to unblock the line
If nothing helps reset the I2C peripheral using RCC register (it has to be implemented on all connected boards).
I have started a threat to read/write SPI flash memory for s3c2440 Microcontroller. All register setting are done properly and flash memory read/write functionality working perfectly.
S3c2440(ARM9) spi_read_write Flash Memory
Now, I want to do the same thing with "S3C2451 16/32-Bit RISC Microprocessor"
Then what will be the register configuration for "S3C2451" to achieve the same?
I have studied and compared both the datasheet "S3C2440A" and "S3C2451" and found that so many register are different. I have also notice that in datasheet says "S3C2440A" is "32-BIT CMOS MICROCONTROLLER" and "S3C2451
" is "16/32-Bit RISC Microprocessor". So, Is it not the same architecture wise?
So, please guide me to achieve the same.
UPDATE
I got a link of nearly similar code of s3c6410. But at a glance I am not able
to understand what will be the minimum register configuration for
configuring SPI channel 0 with 5 MHz clock output.
http://read.pudn.com/downloads131/sourcecode/embed/558985/Components/con...
I want to configure it for s3c2451 Processor. Please guide me .....
Thanks in advance.