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.
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.
For a project I'm thinking of using this relatively new IC from TI - the ADS7138. The issue (I believe, though I may be wrong) is that there is no driver for this chip in the kernel. Does anyone have any suggestions for a work around to talking to this driver? Is there another driver I could use or am I stuck writing a custom driver specific for this IC?
I've worked on a board bring-up project with the same IC. I couldn't find a driver for it so I wrote one myself. I hope it works for you as well:
ADS7138 Driver
Till you find a compatible kernel driver or develop one yourself, you can quickly experiment with the ADC from user space using the i2c-tools. You can use either the command line tools or use the API to write your own app, but be cautious if you use the command line tools like i2cget(8), first read the man pages and pay attention to the warning section.
To use the API, open(2) the i2c device, set the slave address with ioctl(2), then use smbus APIs like i2c_smbus_write_word_data(), i2c_smbus_read_word_data() etc. You may take a look at the tools code like i2cget.c itself to see how the API is used. Following is a simple code to read a register from an I²C chip connected to /dev/i2c-0.
int fd = open("/dev/i2c-0", O_RDWR);
ioctl(fd, I2C_SLAVE, slave_address);
__s32 res = i2c_smbus_read_word_data(fd, register_address);
close(fd);
See kernel documentation or the web about i2c/smbus and instantiating i2c devices for more details.
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 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
RESOLVED
After much confusion and frustration, I finally got my hard disk to interrupt. :D It basically came down to the fact that I kept reading the status register instead of the alternate status register. A few other things were messed up to boot, but the point is my hard disk driver is finally starting to take shape. Now, for others I will leave the original post.
P.S. For further clarification, I didn't need to issue any sort of reset command. All I did was the following:
Select the device (didn't want to kill the Solaris OS on the other disk)
clear the nIEN bit in the DEVICE CONTROL register
issue an IDENTIFY DEVICE command***
Actually, I am not sure if the IDENTIFY DEVICE command is need because I left the lab happy before I could test the code without issuing the command. However, the main point is that I needed to be sure to read the alternate status register and have the nIEN bit cleared without the need for a reset. The BIOS apparently takes care of most stuff.
I am currently trying to write a disk driver for a hobby OS being developed at my school. I currently have routines to read/write data in the PCI configuration space and assembly routines to do port IO with the various registers defined by ATA/ATAPI-7. Now, my question is, specifically how will I get an IDE hard drive to start generating interrupts? I have been looking through all this documentation and is hasn't become clear to me what I am doing wrong.
Can someone explain exactly what causes an IDE hard drive to start generating interrupts? I already have an interrupts service routine ready to test, but am having difficulty getting the interrupts in the first place. Can this be accomplished through the ATA SOFT RESET?
Thanks!
UPDATE: Ok, I was able to get the secondary channel, an ATAPI CDROM to generate interrupts by setting the SRST bit in the DEVICE CONTROL register for a soft reset. This does not work for the hard disk on the primary channel. What I have noticed so far is that when I set the SRST bit for the HDD, it sets the BSY bit and leaves it set. From there I don't know what to do.
This reference should help you a fair bit: Kenos description of programming ATA/ATAPI.
The basic mechanism to enable interrupts is to clear nIEN in the DCR (Device Control Register):
nIEN: Drive Interrupt Enable bit. The enable bit for the drive interrupt to the host. When nIEN is 0 or the drive is selected the host interrupt signal INTRQ is enabled through a tri state buffer to the host. When nIEN is 1 or the drive is not selected the host interrupt signal INTRQ is in a high impedance state regardless of the presence or absence of a pending interrupt.
This www.ata-atapi.com is a good jumping-off point to find way more info about ATA/PATA/SATA/ATAPI than you want to know... Note that the official ATA-6/7/etc specs cost $$ from T13, though you can download current drafts of ATA-8 from them.
This link describes a few of the many ways ATA devices vary from the specs. (I used to write SCSI and ATA/ATAPI drivers for Commodore/Amiga, way back when, as well as help with qualifying drives - or more accurately, figuring out what idiocies drive makers had done.)
if this is just a hobby OS, why not use the BIOS interrupt (int 13h)? admittedly not as fast as direct disk access but safer for your hard drive (I've put a read head through a plate before messing with disk I/O).