SPI subsystem sitting between BCM7358 and SPI NOR flash use B-SPI module to perfrom read operation and M-SPI module to perfrom the write operation....If I have to perfrom read operation from M-SPI as an substitute of B-SPI...then how can I proceed....any suggestion are welcomed
You will need to find the programming information for the master spi interface, or else find a driver module compatible with your OS or example code you can crib from.
Assuming you want to do the access while your system is running rather than in order to boot from the SPI, what you want to do seems pretty reasonable so the chances of finding useful information are good.
If you are trying to do this to boot, you may need to boot a small bootloader from something else which can "manually" load an image with the master spi and then jump into it. Or else see if the chip has a mode pin combination or the like to boot from the master spi interface instead.
Essentially, if you made your own board and sourced chips without data sheets, you are in trouble unless you can find something else using a similar enough chip to crib from. Similarly if you are hacking a modification to a product without any source code. But if you bought an eval board or module, presumably you have access to some documentation or example code for the board, even if not for the chip.
Related
I'm totally a newbie in embedded software. Currently, I'm working on a project that implements an image processing pipeline on an ARM Cortex-M4 based MCU(board model: STM32F446RE).
I would like to be able to configure the parameters of the pipeline on the fly without actually update the entire firmware since we're using LoRa which has low bandwidth.
I have googled for several hours and could not find any valid solution. So could you please point me in a direction? Thank you very much.
BTW, I don't know if this is relevant, but I'm using FreeRTOS kernel with CMSIS RTOS API v2.
If you are asking this question, I would hope that either:
The board is still under design or
You have a board that was designed by someone who has thought about these issues.
If #2, speak to whoever designed the board, and find out what resources were put in, to handle these issues.
If #1, presumably you have input into the design.
Necessary resources:
Non-volatile storage: flash, eeprom, etc.
One or more ways to write parameters to that non-volatile storage
Desirable resource: communication line for input/output while running (serial is often used).
Once you have these resources, you do the following:
Design the variables, data structures, etc. to hold the parameters
Design your non-volatile storage, taking into account:
a. The features/limitations of your media (for example, flash memory generally requires an erase before writing. Erase takes time and must be done by sector, not individual bytes.
b. Verification: your program should have a way to verify that the non-volatile storage has valid values, not garbage, not all 0xFFs, and either fail or use defaults or some such, if it is not valid
Then you can write a program using this.
You need to consider how you will write the values to the non-volatile memory
during development
in production
They are not likely to be the same.
During development, you want to be able to easily change values. You may have a way to burn your flash chip via a JTAG. You may have a communications port which either runs some kind of simple CLI, accepts commands via some protocol, asks questions and reads the answers via a terminal emulator, etc. The program can then write the values to the non-volatile memory.
In production, you will likely want to burn the 'correct' values once, when setting up the system, without too much operator involvement.
This is just a starting guideline...as mentioned in the comments, your question is very general.
I'm running out of memory with my STM32F107. Unfortunately is 256kb the maximum size of this MCU and there is no pin compatible alternative.
I found several Flash Modules and I know there are ways to boot from it, but I never done that before and I dont know if its possible with the STMF107.
Have someone tried that? Is SPI fast enough, I read something about QSPI, but the STM doesnt support that.
Here the Datasheet from the STM: https://www.st.com/resource/en/datasheet/cd00220364.pdf
Here the Datasheet from the favorite Flash: https://www.mouser.de/datasheet/2/198/IS25LP032-064-128-463542.pdf
The only way you would be able to do this with your microcontroller and that flash is to copy the code into ram and execute it from there. This is not a great solution.
The QSPI interface in some STM32 microcontrollers is different to regular SPI, it has 4 data lines, and is memory mapped, which allows it to be executable, the 'regular' SPI interface has no means for execution of code.
Why would the file system (CIRCUITPY) of an Adafruit board running CircuitPython not show up when connecting it to a suitable host via a micro usb cable?
This happens to me often, usually when I am copying files via Windows, most often with my trinket which uses the integrated chip flash memory rather than the separate SPI flash chip. Why? I don't know. A bug somewhere obviously. :)
So the solution.
Always save your work files locally or use a source code solution like git
Switch to the boot mode (double click reset)
Drag the erase.uf2 file to clear the flash memory
Drag the circuit python uf2 file to reflash python
Restore your files saved on your PC
Basically, I've made it a habit to assume the flash memory is temporary and volatile and not store any critical code only there.
You can read more about the erase uf2 and reflashing, general troubleshooting here:
https://learn.adafruit.com/welcome-to-circuitpython/troubleshooting
Besides your first answer about the cable, because of the relatively inexpensive nature of the boards and direct access to their power/ground sometimes the EPROMs that the file system are hosted on just go bad and give unexpected results. Best idea is to:
Test your environment with another board.
Reflash micro python on your board so you can start from scratch (didn't mention if you'd tried that).
JerryN mentioned the most common cause of this is using a USB cable with no data wires. Some USB cables are designed for power-only and have 2 rather than 4 conductors. These will power the device but will prevent mounting of the drive and use of the serial connection over USB.
Unfortunately these cables are often not marked as power-only so can be difficult to spot.
Another case is where CPLAYBOOT (this varies per board, e.g. GEMMABOOT, FEATHERBOOT, TRINKETBOOT) disappears on Windows. This can be caused by installation of the Arduino software which has an old, conflicting driver from 2007. More information on Adafruit: Circuit Playground Express: Troubleshooting.
A very rare case is a mis-seated USB connector. In my case the power was ok but the data wasn't for a good quality cable which had previously worked fine. Unplugging the USB cable at the host end and re-inserting it solved the problem.
I am working with a simple PIC18F2550 and I'm wondering about how to get a bootloader working on it. It's a very simple device with a USB port and CDC firmware. When I download Tiny Bootloader onto the pic, my PC doesn't recognize the device. Do I NEED to have a USB controller in my circuit in order for it to work? Such as the MAX232?
Would the same apply to the PIC32MX795F512L?
Thanks!
It is clear from the Tiny PIC boot loader documentation that it expects a UART connection rather than USB (that is what the MAX232 is for - it is an RS232 line driver).
You could simply do that and use an external serial to USB converter thus saving the code space required by the USB-CDC stack. Otherwise you will have to modify the boot loader code to use the CDC driver rather than the UART.
You will have to link the USB code with the boot loader, which will no doubt significantly increase its size. You may need therefore also to move the application start address to accommodate the boot loader. Furthermore, if the application needs USB comms, you may need a separate copy of the code in the application unless you provide a method of accessing the bootloader code from the application; which is possible, but not necessarily straightforward.
All that said, note the part at the end of the end of the page about extending the bootloader; On the face of it it seems unsuited to extension. Without looking at the code and its memory map, it is not clear why it has this constraint.
The PIC18F2550 has a USB interface built into it. It is called the "USB SIE" and there is a large section in the datasheet that documents it. If you make the right electrical connections, you should be able to connect your PIC18F2550 directly to a USB port without any active electronics between them. There is no reason you would need extra USB hardware just because you want to run a bootloader.
If you want to troubleshoot your problems with the bootloader, you should probably post another question with more details. It could be a problem with the PIC's configuration bits or something like that. I recommend trying to modify the bootloader to get it to blink an LED as a basic first step just so you can verify that you were able to get its code to run at all.
I have a doubt regarding the reset due to power up:
As I know that microcontroller is hardwired to start with some particular memory location say 0000H on power up. At 0000h, whether interrupt service routine is written for reset(initialization of stack pointer and program counter etc) or the reset address is there at 0000h(say 7000) so that micro controller jumps at 7000 address and there initialization of stack and PC is written.
Who writes this reset service routine? Is it the manufacturer of microcontroller chip(Intel or microchip etc) or any programmer can change this reset service routine(For example, programmer changed the PC to 4000h from 7000h on power up reset resulting into the first instruction to be fetched from 4000 instead of 7000).
How the stack pointer and program counter are initialized to the respective initial addresses as on power up microcontroller is not in the state to put the address into stack pointer and program counter registers(there is no initialization done till reset service routine).
What should be the steps in the reset service routine considering all possibilities?
With reference to your numbering:
The hardware reset process is processor dependent and will be fully described in the data sheet or reference manual for the part, but your description is generally the case - different architectures may have subtle variations.
While some microcontrollers include a ROM based boot-loader that may contain start-up code, typically such bootloaders are only used to load code over a communications port, either to program flash memory directly or to load and execute a secondary bootloader to RAM that then programs flash memory. As far as C runtime start-up goes, this is either provided with the compiler/toolchain, or you write it yourself in assembler. Normally even when start-up code is provided by the compiler vendor, it is supplied as source to be assembled and linked with your application. The compiler vendor cannot always know things like memory map, SDRAM mapping and timing, or processor clock speed or what oscillator crystal is used in your hardware, so the start-up code will generally need customisation or extension through initialisation stubs that you must implement for your hardware.
On ARM Cortex-M devices in fact the initial PC and stack-pointer are in fact loaded by hardware, they are stored at the reset address and loaded on power-up. However in the general case you are right, the reset address either contains the start-up code or a vector to the start-up code, on pre-Cortex ARM architectures, the reset address actually contains a jump instruction rather than a true vector address. Either way, the start-up code for a C/C++ runtime must at least initialise the stack pointer, initialise static data, perform any necessary C library initialisation and jump to main(). In the case of C++ it must also execute the constructors of any global static objects before calling main().
The processor cores normally have as you say a starting address of some sort of table either a list of addresses or like ARM a place where instructions are executed. Wrapped around that core but within the chip can vary. Cores that are not specific to the chip vendor like 8051, mips, arm, xscale, etc are going to have a much wider range of different answers. Some microcontroller vendors for example will look at strap pins and if the strap is wired a certain way when reset is released then it executes from a special boot flash inside the chip, a bootloader that you can for example use to program the user boot flash with. If the strap is not tied that certain way then sometimes it boots your user code. One vendor I know of still has it boot their bootloader flash, if the vector table has a valid checksum then they jump to the reset vector in your vector table otherwise they sit in their bootloader mode waiting for you to talk to them.
When you get into the bigger processors, non-microcontrollers, where software lives outside the processor either on a boot flash (separate chip from the processor) or some ram that is managed somehow before reset, etc. Those usually follow the rule for the core, start at address 0xFFFFFFF0 or start at address 0x00000000, if there is garbage there, oh well fire off the undefined instruction vector, if that is garbage just hang there or sit in an infinite loop calling the undefined instruction vector. this works well for an ARM for example you can build a board with a boot flash that is erased from the factory (all 0xFFs) then you can use jtag to stop the arm and program the flash the first time and you dont have to unsolder or socket or pre-program anything. So long as your bootloader doesnt hang the arm you can have an unbrickable design. (actually you can often hold the arm in reset and still get at it with the jtag debugger and not worry about bad code messing with jtag pins or hanging the arm core).
The short answer: How many different processor chip vendors have there been? There are many different solutions, as many as you can think of and more have been deployed. Placing a reset handler address in a known place in memory is the most common though.
EDIT:
Questions 2 and 3. if you are buying a chip, some of the microcontrollers have this protected bootloader, but even with that normally you write the boot code that will be used by the product. And part of that boot code is to initialize the stack pointers and prepare memory and bring up parts of the chip and all those good things. Sometimes chip vendors will provide examples. if you are buying a board level product, then often you will find a board support package (BSP) which has working example code to bring up the board and perhaps do a few things. Say the beagleboard for example or the open-rd or embeddedarm.com come with a bootloader (u-boot or other) and some already have linux pre-installed. boards like that the user usually just writes some linux apps/drivers and adds them to the bsp, but you are not limited to that, you are often welcome to completely re-write and replace the bootloader. And whoever writes the bootloader has to setup the stacks and bring up the hardware, etc.
systems like the gameboy advance or nds or the like, the vendor has some startup code that calls your startup code. so they may have the stack and such setup for them but they are handing off to you, so much of the system may be up, you just get to decide how to slice up the memorires, where you want your stack, data, program, etc.
some vendors want to keep this stuff controlled or a secret, others do not. in some cases you may end up with a board or chip with no example code, just some data sheets and reference manuals.
if you want to get into this business though you need to be prepared to write this startup code (in assembler) that may call some C code to bring up the rest of the system, then that might start up the main operating system or application or whatever. Microcotrollers sounds like what you are playing with, the answers to your questions are in the chip vendors users guides, some vendors are better than others. search for the word reset or boot in the document to try to figure out what their boot schemes are. I recommend you use "dollar votes" to choose the better vendors. A vendor with bad docs, secret docs, bad support, dont give them your money, spend your money on vendors with freely downloadable, well written docs, with well written examples and or user forums with full time employees trolling around answering questions. There are times where the docs are not available except to serious, paying customers, it depends on the market. most general purpose embedded systems though are openly documented. the quality varies widely, but the docs, etc are there.
Depends completely on the controller/embedded system you use. The ones I've used in game development have the IP point at a starting address in RAM. The boot strap code supplied from the compiler initializes static/const memory, sets the stack pointer, and then jumps execution to a main() routine of some sort. Older systems also started at a fixed address, but you manually had to set the stack, starting vector table, and other stuff in assembler. A common name for the starting assembler file is CRT0.s for the stuff I've done.
So 1. You are correct. The microprocessor has to start at some fixed address.
2. The ISR can be supplied by the manufacturer or compiler creator, or you can write one yourself, depending on the complexity of the system in question.
3. The stack and initial programmer counter are usually handled via some sort of bootstrap routine that quite often can be overriden with your own code. See above.
Last: The steps will depend on the chip. If there is a power interruption of any sort, RAM may be scrambled and all ISR vector tables and startup code should be rewritten, and the app should be run as if it just powered up. But, read your documentation! I'm sure there is platform specific stuff there that will answer these for your specific case.