Renault SPC 560
Модуль предназначен для удаления данных о столкновении ( Crash Data ) в блоках управления подушками безопасности (SRS Airbag*) фирм Temic и Continental, основанных на процессорах ST SPC560. Данные блоки устанавливаются на автомобили Renault Duster 2, Renault Stepway 2, Renault Logan 2, Lada X-RAY. Модуль позволяет также прочитать и удалить ошибки в этих блоках. Также в модуль включена возможность производить смену конфигурации в блоках на процессорах ST SPC560. Модуль также можно использовать в случае замены блока на автомобили с другой комплектацией, для отключения лишних компонентов после очистки Crash Data и т.п.
Например . У вас есть блок, в котором не можете почистить Crash Data . Вы берете дамп от подобного блока, заливаете его в ЭБУ сторонними средствами и далее уже с помощью модуля делаете нужную вам конфигурацию.
Дополнительно в модуль включена возможность производить смену конфигурации в блоках на процессорах Motorola 9s12XDT384и с внешней eeprom 95640. Данные блоки устанавливались на автомобили Renault Fluence III и Renault Megane III.
Работа может производится как через диагностический разъем автомобиля, так и на столе при соответствующем подключении блока. Для работы необходимо наличие адаптера J2534. При работе с блоком на столе если используемый вами для работы адаптер J2534 не имеет внутренней подтяжки CAN BUS, то установите дополнительный резистор сопротивлением 120 Ом между шинами CAN High и CAN Low.
Запустите программу и подключите адаптер J2534 к свободному USB порту вашего компьютера. Нажмите Настройки, в открывшемся окне выберите пункт Настройка адаптера J2534 и в следующем открывшемся окне выберите J2534 устройство, которое используете для работы. Выбранный адаптер отобразится в нижней левой части основного окна программы. Выберите в программе модуль SRS Renault SPC, затем марку нужного вам блока SRS в соответствующей вкладке модуля (Temic или Continental).
Нажмите кнопку Read . Если подключение произведено правильно, то в окне информации отобразятся идентификационные данные блока управления, а также ошибки и запись о Crash Data , при их наличии.
Для удаления данных о столкновении ( Crash Data ) нажмите кнопку CLEAR в разделе программы Clear Crash
Программой автоматически будет очищен блок от Crash Data, о чем будет выведено соответствующее сообщение в информационном окне. После этого удалите ошибки, нажав кнопку CLEAR в разделе программы DTC
В результате срабатывания подушки безопасности блок управления подушками безопасности может оказаться заблокированным, что делает невозможным его нормальное функционирование, удаление ошибок и т.д.
Если у вас нет дилерского прибора CAN Clip, то для разблокировки блока управления подушками безопасности нажмите кнопку UNLOCK . Блок будет разблокирован о чем будет выведено соответствующее сообщение в информационном окне.
Дополнительно модулем можно производить смену конфигурации в блоках, отключить или подключить датчики и исполнительные механизмы системы SRS, переписать VIN блока рулевого управления, блока SRS или панели приборов, что дает возможность использовать эти детали от других автомобилей.
Для смены конфигурации исполнительных механизмов сначала нажмите кнопку Исп.Мех .
В открывшемся окне программы нажмите кнопку Read Cohfig для чтения текущей конфигурации.
Отключите не нужные и включите нужные вам исполнительные механизмы соответствующими переключателями и нажмите кнопку Write Cohfig для того, чтобы записать изменения в блок.
Для смены конфигурации датчиков системы SRS сначала нажмите кнопку ДАТЧИКИ .
В открывшемся окне программы нажмите кнопку Read Cohfig для чтения текущей конфигурации
Отключите не нужные и включите нужные вам датчики соответствующими переключателями и нажмите кнопку Write Cohfig для того, чтобы записать изменения в блок.
Для того, чтобы переписать VIN блока рулевого управления, блока SRS или панели приборов нажмите кнопку VIN
В открывшемся окне выберите блок автомобиля, в котором нужно прочитать или переписать VIN и нажмите кнопку Read.
Программа прочитает текущий VIN данного блока и отобразит его в соответствующем поле.
Измените VIN в этом поле на нужный вам и нажмите кнопку Write
Все выполняемые операции будут отображаться в окне информации.
После всех операций по смене конфигурации необходимо очистить ошибки в блоке.
Внешний вид блока SRS Renault Fluence III
Внешний вид блока SRS Continental A2C80612810 SPC560P50L3. Renault Logan 2
Подключение на столе блока SRS Renault Fluence III
Подключение на столе блока SRS Continental Renault Logan 2, Daster 2
E:\BCM VESTA\Project 9 CFLASH program example\Example_MPC5643L-Flash_program_simple_v0_0_CW210\MPC5643L-Flash_program_simple_v0_0_CW210\src
Renault Sandero II чистим Crash дату блока Continental SRS
Авто Renault sandero II был легкий удар, без выстрела подушек. Машину удалось завести с помощью Clip’a. Но информация об аварии все равно висела в блоке SRS, пузатый чувак на панельки дико раздражал, ну и неисправность самой системы SRS — небезопасно :))
Было принято решение, избавляемся от краш даты, покупать новый блок клиент разумеется не хотел)).
В данном авто стоит блок SRS Continental A2C80612810. Внутри стоит процессор SPC560P50L3.
В продаже есть огромное кол-во программаторов которые умеют работать с данным процом.
Я остановился на Mac/Mpc/Spc Programmer (в народе называют как Macaca).
Все это было заказано на сайте EcuTools. Ехало все это добро долго, пришлось ждать т.к. в наличии их не было.
Пока ждал "макаку" было время изучить инфу по данным блокам. В принципе проблем никаких этот блок вызвать не должен.
Получив наконец "Макаку" приступили к работе.
Сразу хотелось бы уточнить. У блока есть один нюанс. В сети было много инфы, что после чтения процессора была непонятная ошибка "НЕИСПРАВНОСТЬ МОДУЛЯ". Эта ошибка вылезала только в том случае, если вы используете для чтения внешний источник питания самого блока. Вероятно этот блок относится к тем блокам, которые не любят включения без автомобиля и всей обвески. Поэтому питание я использовал от самого программатора 3V.
Снимаем с машины сам блок SRS. Разбираем блок и подключаем к "макаке".
SPC560P50L3 unsupported read write?
This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.
SPC560P50L3 unsupported read write?
I’m trying to read back flash of SPC560P50L3 IC and erase sectors. Reading somehow goes on (when I switched off USE RAM), but when I write or erase there is a message:
SEGGER — Erik
We are not aware of any problems regarding flash programming of the SPC560P50L3.
We gave it a quick try with the latest software version (V4.80f) and everything works just fine.
We are able to read back / erase flash / program flash / verify flash. without any problems.
I assume you are using J-Flash for your purposes? What debug probe do you use?
It seems to me that the project is not configured correctly.
Can you please give the attached J-Flash project a quick try and provide some feedback?
If it does not solve the problem please provide us your used project.
Best regards
Erik
(1.87 kB, downloaded 1,366 times, last: Oct 11th 2022, 2:47pm )
Please read the forum rules before posting.
Keep in mind, this is *not* a support forum.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support you can contact us via our support system: segger.com/ticket/
Or you can contact us via e-mail.
This file does not work for me.
It reads only when I switch off the flag Use Target RAM.
This config stops by error "core does not stop after halt". The log following:
SEGGER J-Link V4.80e DLL Log
DLL Compiled: Jan 31 2014 18:10:51
Logging started @ 2014-02-07 17:35
T0854 090:134 JLINK_Reset() — Type: 0
T08C0 090:191 JLINK_WriteMem(0x40000000, 0x0800 Bytes, . ) — Data: 00 01 02 03 04 05 06 07 .
T08C0 090:206 JLINK_ReadMem (0x40000000, 0x0800 Bytes, . ) — Data: 00 01 02 03 04 05 06 07 .
T08C0 090:378 JLINK_WriteMemEx(0x40000000, 0x0508 Bytes, . AccessWidth = 0) — Data: 00 00 E8 00 E8 50 E8 3E .
T08C0 090:389 JLINK_ReadMemEx(0x40000000, 0x0508 Bytes, . AccessWidth = 0) — Data: 00 00 E8 00 E8 50 E8 3E .
T08C0 090:399 JLINK_WriteReg(R4, 0x400005E8) returns 0x00
T08C0 090:399 JLINK_WriteReg(R5, 0x00007A18) returns 0x00
T08C0 090:399 JLINK_WriteReg(R1, 0x400005C8) returns 0x00
T08C0 090:399 JLINK_WriteReg(PC, 0x4000000A) returns 0x00
T08C0 090:399 JLINK_GoIntDis()
T08C0 090:423 JLINK_ReadReg(PC) returns 0x40000002
T08C0 090:423 JLINK_ReadReg(MSR) returns 0x00000000
T08C0 090:423 JLINK_ReadReg(R3) returns 0x00007A18
T08C0 090:423 JLINK_WriteReg(R1, 0x400005C8) returns 0x00
T08C0 090:423 JLINK_WriteReg(PC, 0x4000000C) returns 0x00
T08C0 090:423 JLINK_GoIntDis()
T08C0 090:435 JLINK_ReadReg(PC) returns 0x40000002
T08C0 090:435 JLINK_ReadReg(MSR) returns 0x00000000
T08C0 090:435 JLINK_WriteReg(R4, 0x00000000) returns 0x00
T08C0 090:435 JLINK_WriteReg(R5, 0x00008000) returns 0x00
T08C0 090:435 JLINK_WriteReg(R6, 0xFFFFFFFF) returns 0x00
T08C0 090:435 JLINK_WriteReg(R1, 0x400005C8) returns 0x00
T08C0 090:435 JLINK_WriteReg(PC, 0x40000008) returns 0x00
T08C0 090:435 JLINK_GoIntDis()
T08C0 095:438 JLINK_Halt()
Ok. I’ve connected to CPU finally. And can confirm. Yes J-Link reads and writes this chip.
But!
Once I’ve loaded a program into it and powered off/on, it becomes unreadable.
Thats what it writes:
— Initializing CPU core (Init sequence) .
— Executing Reset (0, 0 ms)
— ERROR: PowerPC: OnCE-Id mismatch
— ERROR: Failed to connect
I’ve tested this on two IC. How can you comment this?
—
I’ve added Delay of 20ms and it solved the connection problem
Now I’ve another problem:
Erasing chip .
— Erasing 12 sectors, 2 ranges, 0x0 — 0x7FFFF, 0x800000 — 0x80FFFF
— ERROR: PC of target system has unexpected value after checking target RAM. (PC = 0x00000000, MSR = 0x00000000)!
— ERROR: Failed to erase chip
The post was edited 1 time, last by zend ( Mar 12th 2014, 1:47pm ).
SEGGER — Alex
That’s how I comment on this:
I have no idea *what* application you are programming into the device but if it works once and not anymore after the
application started running, I suspect: Your application puts the CPU in a non-responsive / non-usable state regarding debugging.
Possible problems:
— CPU is put into low power mode which disables all clocks of the debug interface, so debugger connection is no longer possible
— Application protects CPU against debugger connection (activating read protection etc. which disables the debug interface)
Please read the forum rules before posting.
Keep in mind, this is *not* a support forum.
Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
Should you be entitled to support you can contact us via our support system: segger.com/ticket/
Or you can contact us via e-mail.
You’re totally wrong. This application works well. I just copied it from the working device.
You’ve also not read the rest of my topic, where I’ve written, that when timeout has been added to Init procedure, the connection has been established.
I can also read ECU but not using Internal RAM. Internal RAM not responding correctly.
Thats what I think.
The program works, but it takes some CPU rate, and programmer does not wait for any timeouts when makes requests.
Is there any way to set such JTAG timeouts?
By the way, I’ve another programmer that can read this CPU well, so your diagnose is far away from the trueth.
SEGGER — Alex
Seems you did not understand the question.
I never wrote that your application is not working. I wrote that it may inhibit the debugger from connecting again, once it is running.
These are two different things:
You can have a perfectly working application but if it re-configures for example the JTAG pins for GPIO usage, a debug probe / programmer
cannot connect any longer to the device, even though the application itself is running fine.
Wow, so why do you not share such information with us? I do not see *anything* regarding another working probe in your previous posts.
But enough of the p*** contest, let’s try to be productive.
a) It is working here, so Flasher in general is working
b) It works on your side until(!) you program your application into the device once and let it run (by power cycling the device).
After b), it is not working anymore with the configuration you used before (and which worked before). You had to add some delay (no idea where you add that delay, but I assume in the init sequence)
So there is definitely something different after(!) you programmed the application to the target.
So there may be a special case the target may be in that is not handled yet perfectly by Flasher PPC, but this is something that can be improved.
The problem is: Without being able to reproduce this here, there is not much we can do to help, since we only see it working here.
Can you provide the image you are programming into the device, so we can give the same image a try here?
What if you select "Target -> Generate test data" and program these multiple times (also with having the target power cycled between the programming sessions, so "the application" runs)
Do you see the same behavior as when you are using your application image?