The current MCU we are using CY90F598GPFR-GSE1 already had last buy and we cannot get any more.Our representative mentioned, that they might be able t...
The current MCU we are using CY90F598GPFR-GSE1 already had last buy and we cannot get any more. Our representative mentioned, that they might be able to get the CY90F598GDPF-GSE1 although it already had last buy.
But have not been able to find anywhere, what the difference in part number means, neither does our contact. The models share GPF, while one has the suffix R, which as I understand is a backend fab indicator.
But the D it's a mystery, and was not able to find this info anywhere. Anyone who knows or can point me in the right direction?
Hallo,I'm looking for an alternative of the Mb90f347caspf-e1. Let's have a look to the part number
Now it is called CY.. (Cypress). The "34" is the fa...
Hallo, I'm looking for an alternative of the Mb90f347caspf-e1. Let's have a look to the part number
Now it is called CY.. (Cypress). The "34" is the family, '7' indicates the memory (64K Flash, 6K RAM). Ther parts with a '3', '2' and '9' has more memory (really? only more memory?). They should work. 'c' and 's' are some functional options. "pf" is the case, isn't it? What is the meaning of 'a' and "-e1"? Will my Programm run on a Mb90f342cespf ('2': more Memory -> no problem, 'e' instead of 'a': what is that?).
Or easier for all: Is there full part numbering table of the MB90 (CY90) family available?
We have been using the CY90F598GPFR-GE1 MCU for quite some time, but unfortunately completely missed the last buy. Does any suitable replacement exist...
We have been using the CY90F598GPFR-GE1 MCU for quite some time, but unfortunately completely missed the last buy. Does any suitable replacement exist which is not already obsolete, or otherwise if We could be so lucky as to find the MCU still in stock somewhere?
I need to read/write this MCU flash memory.For this purpose I can use free Fujitsu tool "FR MCU Programmer V01,L28"and respective connectio...
I need to read/write this MCU flash memory. For this purpose I can use free Fujitsu tool "FR MCU Programmer V01,L28" and respective connection to PC COM-port. The problem is that this MCU-model isn't included in this version of the program: neither in chipdef.ini file, nor as respective hex-file "m_flash.011" (specific for each MCU) in the program directory.
In order to add MB91F011 in chipdef.ini file, I have to know "LoadAddress", but I can't find any document for this MCU. I guess that: - "LoadAddress" is the start address in the internal-RAM-memory space, where hex-file "m_flash.011" = kernel has to be loaded from the PC. - "StartAddress" and "EndAddress" are the boundaries of the internal-FLASH-memory.
Those my decisions are based on existing settings for MB91F109 in chipdef.ini file and existing document for this MCU-model.
The other option for this topic is to use other free tool- "Fujitsu Flash Kit Programmer 2.9". But there are same problems with config-file (Serial.cfg) and hex-file (aMB91F011.mhx), as MB91F011 isn't included in this tool version too. It seems that the versions of both tools are too fresh, so MB91F011 is excluded. And I can't find any older version, where MB91F011 is included.
Could you help me with documents and settings for MB91F011 internal flash operations ?
I currently working on FR81s MCU MB91524FS with SOFTune Compiler V65L06R01 for FBL project and I have 2 issue with compiler generated code i...
I currently working on FR81s MCU MB91524FS with SOFTune Compiler V65L06R01 for FBL project and I have 2 issue with compiler generated code in FBL running environment, that is, no Flash code access during Flash operation.
1, the switch-case code generation:
it looks to me that the compiler generated a 'branch_table' for some switch-case C code. here is the example:
RA 00000814 9F8D00000000 R 2832 LDI:32 #L_50415,R13 RA 0000081A B420 2833 LSL #2,R0 RA 0000081C 0000 2834 LD @(R0,R13),R0 2835 ;-------table_branch RA 0000081E 9700 2836 JMP @R0 2837 CO 00000018 -----------<CONST>----------- 2838 .section CONST, CONST, ali gn=4 CO 00000018 - 00000018  <  2839 .align 4 CO 00000018 2840 L_50415: 2841 ;-------begin_of_branch_table CO 00000018 00000000R 2842 .word L_293 CO 0000001C 00000000R 2843 .word L_288 CO 00000020 00000000R 2844 .word L_290 CO 00000024 00000000R 2845 .word L_293 CO 00000028 00000000R 2846 .word L_293 CO 0000002C 00000000R 2847 .word L_291 2848 ;-------end_of_branch_table 2849 RA 00000820 ----------<RAMCODE>---------- 2850 .section RAMCODE, CODE, al ign=2 RA 00000820 - 00000820  <  2851 .align 2
because this table is CONST section located in Flash, while the function contains this switch-case code shall be relocated to RAM (RAMCODE) for Flash operation, that would cause MCU hung. my question is is there any way to prevent compiler to generate so call branch table?
2, the 2nd question is about Intrinsic function
the C division '/' would involve compiler intrinsic function from Lib911, i could see that function like ' __divxx' was allocated in Flash, so as the first scarino, in FBL when Flash is not accessible for read, a division code would result in MCU hung.